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PREFACE 


The  purpose  of  this  manual  is  to  enable  an  analyst,  engineer 
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CHAPTER  1 .  GENERAL 


This  manual  was  developed  to  assist  the  user  in  operating 
the  Achieving  a  System  Operational  Availability  Re^guirement 
(ASOAR)  computer  model.  Currently,  ASOAR  can  handle  a  system 
with  as  max./  as  99  end  items. 

ASOAR  is  written  in  Fortran  77 .  This  is  relevant  because 
Fortran  has  strict  input  and  output  formats.  Real  numbers  are 
distinguished  by  coliunns  headed  with  the  letter  "F",  while 
integer  numbers  are  headed  with  the  letter  " I " .  Alphanumeric 
inputs  are  distinguished  by  columns  headed  with  the  letter  "A" . 
When  asked  to  input  a  number,  line  up  the  numerals  and  the 
decimal  point  under  the  column  headings  that  appear.  For  real 
numbers,  leading  and  trailing  zeros  may  be  left  out.  For 
example,  0.5  may  be  inputted  as  .5,  and  2.50  may  be  inputted  as 
2.5.  Only  leading  zeros  may  be  omitted  for  integer  numbers,  but 
the  numerals  must  be  right-adjusted  under  the  column  headings. 

When  creating  a  file,  the  rules  for  naming  the  file  follow 
the  conventions  of  MS-DOS.  A  filename  can  be  up  to  8  characters 
in  length  and  may  have  an  optional  extension  of  up  to  3 
characters  ( XXXZXXXX . XXE ) .  The  first  character  of  the  filename 
must  be  alphanumeric.  There  is  no  allowance  for  an  optional 
drive  or  pathname  in  the  filename.  The  location  of  the  data 
file  is  on  the  same  default  drive  that  contains  the  ASOAR 
executable  file. 

ASOAR  computes  Operational  Availability  (Ao)  goals,  order 
fill  rates,  and  other  values  by  doing  hundreds  of  iterations 
where  initial  values  are  incremented  in  very  small  amounts.  The 
output  of  a  diagnostic  printout  shows  all  of  these  intermediate 
values.  Therefore,  it  is  recommended  that  a  diagnostic  printout 
not  be  chosen  unless  the  user  is  prepared  to  spend  considerable 
time  analyzing  all  of  these  intermediate  values.  A  detailed 
explanation  of  the  diagnostic  printout  is  found  in  CHAPTER  10. 
DIAGNOSTIC  PRINTOUT  INFORMATION. 


CHAPTER  2.  GETTING  ST2HITED:  A  SAMPLE  RUN 


Place  the  floppy  disk  containing  the  ASOAR  model  into  the  A 
floppy  disk  drive.  The  user  will  copy  tv:o  files  from  the  floppy 
disk:  the  ASOAR  executable  file,  ASOAR.EXE,  and  the  error  file, 
F77L.EER.  The  error  file  is  executed  to  print  out  the  error  messages 
when  the  program  run  has  errors  such  as  0  divisors  or  when  the  user 
tries  to  open  a  non-existing  file.  These  two  files  should  be  in  the 
same  drive  in  order  to  be  worked  properly.  At  the  C:\>  prompt  (or 
the  prompt  of  your  default  drive)  type: 

C:\>COPY  A: ASOAR. EXE 
After  the  C:\>  prompt  reappears,  type 

C:\>COPY  A:F77L.EER 

Now  the  user  has  the  two  files  in  the  default  drive  necessary  to 
run  ASOAR  model.  At  the  C;\>  prompt  type 

C:\>ASQAR 

The  following  messages  will  appear  welcoming  you  to  Version  3  of 
the  ASOAR  computer  model. 

When  ASOAR  is  started,  the  first  message  to  the  user  appears  as 
follows : 

WELCOME  TO  VERSION  3.0  OF  THE  ACHIEVING  A  SYSTEM 
OPERATIONAL  AVAILABILITY  REQUIREMENT  (ASOAR)  COMPUTER  MODEL. 

THIS  VERSION  OF  ASOAR  WAS  CREATED  BY  CHRISTINE  SHIN  AND 
BERNARD  PRICE  OF  THE  US  ARMY  COMMUNICATIONS  ELECTRONICS 
COMMAND.  WITHOUT  THE  USE  OF  SPECIAL  CASES,  THE  MODEL 
DETERMINES  THE  COST  FTFECTIVE  OPERATIONAL  AVAILABILITY  GOALS 
FOR  EACH  END  ITEM  J'R^IALLY  CONFIGURED  HAVING  THEIR  LINE 
REPLACEABLE  UNIT  (LRU)  SPARES  SUPPLIED  FORWARD  WITH  THE 
SYSTEM.  SPECIAL  CASES  ARE  USED  TO  HANDLE  OTHER  EQUIPMENT 
CONFIGURATIONS,  PERIODIC  DOWNTIME,  CENTRALIZED  FORWARD 
SUPPORT,  AND  END  ITEM  FLOATS  STOCKED  FORWARD. 

PRESS  ENTER  KEY  FOR  NO  DIAGNOSTIC  PRINTOUT  OR  ENTER  1  FOR 
DIAGNOSTIC  PRINTOUT. 

NOTE:  RECOMMEND  PRESSING  THE  RETURN  KEY  UNLESS  INTERMEDIATE 
COMPUTATION  VALUES  ARE  NECESSARY. 

ENTER  THE  KEY  NOW: 

A  diagnostic  printout  will  considerably  delay  the  final  system 
and  end  item  level  output  data.  The  data  that  ASOAR  requires  depends 
on  the  type  of  equipment  reliability  and  maintainability  being 
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specified  by  the  user,  whether  or  not  any  specie.  1  cases  are  being 
considered,  and  whether  the  value  for  the  Mean  Time  To  Obtain  MTTO) 
spares  is  inputted  directly  or  is  computed.  The  user  can  err  :e 
files  with  ASOAR  to  store  some  of  the  inontted  data.  A  list:  r  of 
inputted  data  required  for  ASOAR  is  foui._  >_iiAE— ?  1.  INP’  DATA 

REQUIRED  FOR  ASOAR.  For  this  exercise,  simply  hit  tne  "RETU  '  (or 
"ENTER")  key. 

DO  YOU  WISH  TO  SAVE  THE  OUTPUT  DATA(Y/N)? 

If  the  response  is  "Y" ,  ASOAR  will  ask  for  the  output  fil'  -lame  by 
prompting  the  following: 

ENTER  OUTPUT  FILE  NAME: 

After  inputting  the  file  neime,  the  output  table  will  be  saved  in  the 
output  file  for  later  use.  For  this  exercise,  input  "N" . 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

SHOULD  THERE  BE  ANY  INPUT  MISTAKE  WHICH  CANNOT  BE  CORRECTED, 

YOUR  INPUT  FILE  CMI  BE  MODIFIED  AFTER  THIS  PROGRAM  RUN. 


ENTER  FAILURE  DATA  FILE  NAME: 

Type  the  desired  filename  and  hit  the  RETURN  key. 

ASOAR  will  create  or  use  an  existing  file  with  the  name  inputted 
to  the  question  ENTER  FAILURE  DATA  FILENAME.  The  data  is  stored  in 
that  file  and  the  file  can  be  changed  later  if  different  reliability, 
maintainability  or  cost  data  is  desired.  In  this  example,  type 
"TEST1.DAT". 

WILL  USER  ENTER  DATA  FROM  KEYBOARD  (Y/N)? 

If  the  response  is  "N" ,  ASOAR  will  search  for  the  file  TEST1.DAT 
for  its  reliability,  maintainability,  and  cost  data.  The  data  in  the 
file  will  be  displayed  before  proceeding  to  a  set  of  questions 
dealing  with  the  mean  time  to  obtain  LRU  spares  for  the  end  items  of 
the  system.  If  the  response  is  "Y,"  a  file  will  be  created  from 
answers  to  future  questions  about  each  end  item's  cost,  reliability 
and  maintainability.  If  the  file  already  exists  end  the  response  is 
"Y" ,  an  error  message  will  eventually  appear  saying  that  the  file 
called  by  INPUT  in  ASOAR  cannot  be  opened. 

Since  this  file  does  not  yet  exist,  type  "Y"  and  hit  the  RETURN 

key. 
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HOW  MANY  END  ITEMS  ARE  SERIAIIiY  CONFIGURED? 

II 

This  niunber  represents  the  number  of  different  kinds  of  end  items 
making  up  the  system.  Type  "05"  for  our  exeunples  and  hit  the  RETURN 
key.  The  list  of  reliability  input  options  then  follows: 

IS  THE  MEAN  CALENDAR  TIME  BETWEEN  FAILURE  (MCTBF)  INPUTTED  OR 
COMPUTED? 

1.  MCTBF  IS  INPUTTED  FOR  EACH  END  ITEM. 

2.  MCTBF  IS  COMPUTED  FROM  INPUTS  OF  MEAN  TIME  BETWEEN  FAILURE 
(MTBF)  AND  OPERATING  HOURS  PER  YEAR  INPUTS. 

3.  MCTBF  IS  COMPUTED  FROM  INPUTS  OF  MTBF,  OPERATING  HOURS  PER 
YEAR,  AND  NON-OPERATING  MEAN  TIME  TO  FAILURE  INPUTS. 

4.  MCTBF  IS  COMPUTED  FROM  FAILURE  FACTOR  INPUTS  (FAILURES  PER 
100  END  ITEMS  PER  YEAR). 

ENTER  THE  CODE: 

Mean  Calendar  Time  Between  Failure  (MCTBF)  is  reliability 
terminology  used  internally  for  computations  by  the  ASOAR  model. 

Since  operational  availability  represents  the  probability  that  an 
item  will  be  in  an  operable  or  committable  condition  at  any  random 
point  in  calendar  time,  computations  are  performed  with  calendar  time 
units . 

To  describe  end  item  reliability  inputs  familiar  to  the  user, 
ASOAR  is  flexible  to  use  either  MCTBF,  Mean  Time  Between  Failure 
(MTBF)  or  Failure  Factors.  MTBF  is  equipment  design  reliability 
terminology  specified  in  operating  hours  rather  than  calendar  time 
hours.  Failure  factors  are  the  number  of  failures  per  100  end  items 
per  year. 

If  the  response  if  "1",  MCTBF  is  directly  inputted  for  each  end 
item.  If  the  response  is  "2",  MTBF  and  the  Number  of  Operating  Hours 
per  Year  will  be  inputted.  "2"  assumes  that  the  end  item  does  not 
fail  when  it  is  not  operating.  If  the  response  is  "3",  MTBF,  the 
Number  of  Operating  Hours  per  year  and  the  Non-Operating  Mean  Time  to 
Failure  will  be  inputted.  The  Non-Operating  Mean  Time  to  Failure 
accounts  for  the  end  item  failing  during  hiatus  which  is  when  the  and 
item  is  not  operating.  If  the  response  is  "4",  the  failure  factor  of 
each  end  item  will  be  inputted.  When  MCTBF  is  not  directly  inputted, 
the  ASOAR  model  will  internally  compute  the  MCTBF  so  that  operational 
availability  computations  are  correct.  ASOAR  reliability  outputs 
will  be  recomputed  and  displayed  into  the  terminology  inputted  here 
by  the  user. 

For  our  examples,  type  "1"  and  hit  the  RETURN  key.  The  list  of 
maintainability  input  options  then  follows: 
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IS  THF  MEAN  TIME  RESTORE  (MTR)  IKPDTTED  OR  COMPUTED? 

1.  MTR  IS  IKx'UTTED  FOR  EACH  END  ITEM.  _ 

2.  MTR  IS  EQUAL  TO  THE  MEAN  Tllffi  TO  HEP2LER  (MTTR)  AND  HTTP 

IS  INPUTTED  FOR  EACH  END  ITEM-  _ 

3.  MTR  IS  COMPUTED  FOR  EACH  END  ITEM  FROM  INPUTS  OF  MTTR 
AND  ADDITIONAL  DOWN  TIME  PER  FAILURE  AT  THE 
ORGANIZATIONAL  LEVEL  EVEN  WHEN  LRU  SPARE  '  ARE  AIWAYS 
AVAILABLE. 

ENTER  THE  CODE: 

Mean  Time  to  Restore  (MTR)  is  maintainability  terminology  used 
internally  for  computations  by  the  ASOAR  model.  MTR  represents  the 
average  amount  of  calendar  time  hours  that  an  end  item  would  be  down 
if  Line  Replaceable  Unit  (LRU)  spares  were  alviays  on-hand  to  restore 
the  end  item  to  an  operable  or  committable  condition. 

To  describe  end  item  maintainability  inputs  familiar  to  the  user, 
ASOAR  is  flexible  to  use  either  MTR  or  Mean  Time  to  Repair  (MTTR) . 
MTTR  is  equipment  design  maintainability  terminology  where  LRU  spares 
are  always  on-hand  to  restore  the  end  item  in  an  ideal  logistics 
support  environment. 

If  the  response  is  "1",  MTR  is  directly  inputted  for  each  end 
item.  If  the  response  is  "2",  MTTR  will  be  inputted.  "2"  assumes 
that  additional  logistics  down  time  that  delays  end  item  restoral 
despite  the  spare  LRU  being  on-hand  is  negligible.  If  the  response 
is  “  3 " ,  MTTR  and  the  Additional  Downtime  per  Failure  when  LRU  spares 
are  always  available  will  be  inputted.  Additional  Downtime  per 
Failure  accounts  for  the  delayed  restoral  time  that  may  come  from 
obtaining  on-hand  LRU  spares  from  storage,  not  always  having 
appropriately  educated  or  skilled  personnel  available,  lack  of 
complete  and  correctly  written  maintei'ance  procedures  in  the 
Organizational  Level  technical  manuals,  and  not  always  having 
functioning  tools  and  test  equipment  available  with  the  system.  When 
MTR  is  not  directly  inputted,  the  ASOAR  model  will  internally  compute 
MTR  so  that  operational  availability  computations  are  correct.  ASOAR 
maintainability  outputs  will  later  be  recomputed  and  displayed  in  the 
terminology  inputted  here  by  the  user. 

For  our  exEunples,  type  "1"  and  hit  the  RETURN  key.  The  following 
header  will  appear: 
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SERIALLY  CONFIGURED  END  ITEMS 


END  END 

ITEM  ITEM 

NAME  NUMBER 

AAAAAAAA  II 


END 

ITEM 

COST 

FFFFFFF. 


LOW  FAILURE 
HIGH  COST 
ASSEMBLY 
EXPENSE 
FFFFFFF. 


Each  END  ITEM  NAME  and  corresponding  END  ITEM  NUMBER  are  assigned 
by  the  user.  The  END  ITEM  COST  can  represent  the  actual  dollar  cost 
of  one  end  item,  the  sum  of  the  cost  of  all  assemblies  making  up  the 
end  item,  or  the  relative  cost  of  that  end  item  in  proportion  to  the 
cost  of  the  other  end  items.  The  basis  for  the  END  ITEM  COST  input 
must  be  consistent  for  all  end  items.  The  last  colxunn,  "LOW  FAILURE, 
HIGH  COST  ASSEMBLY  EXPENSE",  allows  for  the  cost  of  a  particular 
assembly  to  be  subtracted  from  the  cost  of  the  end  item  (end  items 
are  composed  of  assemblies).  The  total  costs  of  assemblies  with  a 
significant  percentage  of  the  end  item  cost  and  a  very  low  chance  of 
failure  (such  as  strategic  satellite  dish  structural  components  in  a 
communication  system)  are  to  be  entered.  If  jsuch  an  assembly  exists 
and  its  cost  entered,  the  end  item  cost  will  then  be  internally 
computed  to  be  the  value  in  the  column  "END  ITEM  COST"  less  the  value 
in  the  column  "LOW  FAILURE,  HIGH  COST  ASSEMBLY  EXPENSE".  If  the  end 
item  cost  is  determined  from  the  relative  cost  of  all  the  end  items, 
or  if  a  significant  cost,  very  low  failure  rate  assembly  does  not 
exist  for  the  end  item,  then  a  value  of  zero  should  be  entered  in  the 
"LOW  FAILURE,  HIGH  COST  ASSEMBLY  EXPENSE"  column. 


Type  in  the  following  input  data  for  our  examples  under  the 
appropriate  column  headings  using  the  space  bar  and  the  backspace  key 
to  move  between  fields.  When  you  are  finished  entering  the  data  for 
an  end  item,  hit  the  RETURN  key  and  you  may  then  begin  entering  data 
for  the  next  end  item.  i 


Iteml 

01 

5000. 

0. 

item2 

02 

4000. 

0. 

item3 

03 

1000. 

0. 

ltem4 

04 

2000. 

0. 

Items 

05 

4000. 

0. 

After  the  data  for  the  last  end  item  has  been  entered  and  the 
RETURN  key  hit,  ASOAR  asks  for  the  reliability  data  of  each  end 
item.  The  END  ITEM  NUMBER  will  automatically  appear  and  reliability 
information  corresponding  to  that  end  item  will  need  to  be  inputted. 
The  reliability  inputs  required  for  each  end  item  depends  on  the 
response  previously  made  to  the  list  of  reliability  input  options. 
After  the  end  item  inputs  are  done,  the  next  end  item  number  will 
automatically  appear  before  the  user  enters  its  inputs. 
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If  Option  "1"  was  selected,  the  following  header  would  appear: 

END  ITEM  MEAN  CALENDAR  TIME  BETWEEN  FAILURE 

NUMBER  FFFFFFF. 

1 

The  cursor  will  be  right  below  the  first  F  of  FFFFFFF. 

The  MEAN  CALENDAR  TIME  BETWEEN  FAIUJRES  (MCTBF)  of  each  end 
item  represents  the  average  calendar  time  hours  between  failures 
of  the  end  item.  Besides  the  designed  reliability,  MCTBF  also 
accounts  for  each  end  item's  operating  tempo. 

If  Option  "2"  was  selected,  the  following  header  would  appear: 

END  MEAN  TIME  OPERATING  HOURS 

ITEM  BETWEEN  FAILURE  PER  TEAR 

NUMBER  FFFFFFF.  FFFF.F 

1 

The  MEAN  TIME  BETWEEN  FAILURE  (MTBF)  of  each  end  item 
represents  the  average  operating  hours  between  failures.  MTBF 
is  the  designed  reliability  based  on  equipment  operation.  The 
OPERATING  HOURS  PER  YEAR  accounts  for  the  operating  tempo  of 
each  end  item  and  the  system.  It  is  needed  to  internally 
convert  the  inputted  MTBF  to  MCTBF.  After  results  are  computed 
internally,  the  OPERATING  HOURS  PER  YEAR  inputs  are  used  again 
to  internally  convert  MCTBF  results  to  MTBF  outputs. 

If  Option  "3"  was  selected,  the  following  header  would  appear: 

END  MEAN  TIME  OPERATING  HOURS  NON-OPERATING  MEAN 

ITEM  BETWEEN  FAILURE  PER  YEAR  TIME  TO  FAILURE 

NUMBER  FFFFFFF.  FFFF.F  FFFFFFF. 

1 

Option  "3"  is  similar  to  Option  "2"  except  significant  failures 
can  additionally  occur  when  the  end  item  is  not  operating.  The 
NON-OPERATING  MEAN  TIME  TO  FAILURE  of  each  end  item  represents 
the  average  non-operating  hours  per  failure  in  a  hiatus 
environment  which  is  based  on  the  equipment  not  being  in 
operation.  The  non-operating  hours  per  years  is  computed 
internally  as  (8760.  -  OPERATING  HOURS  PER  YEAR). 

If  option  "2"  or  "3"  were  selected,  ASOAR  will  also  ask  for  the 
system  opeirating  hours  per  year  after  end  item  level  data 
inputs.  The  following  header  would  appear: 
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ENTER  THE  OPERATING  HOURS  PER  YEAR  OF  THE  SYSTEM: 

FFFF.F 

This  input  is  necessary  for  computing  the  system. MTBF  from 
internal  MCTBF  computation. 

If  Option  "4"  was  selected,  the  following  header  would 
appear: 

END  ITEM  FAILURE  FACTOR 

NUMBER  FFFFFF.F 

1 

The  FAILURE  FACTOR  of  each  end  item  represents  the  average 
number  of  failures  for  100  end  items  over  a  calendar  year. 

Type  in  the  following  MCTBF  input  data  associated  to 
choosing  reliability  input  Option  1  in  our  exeunple.  When  you 
are  finished  entering  the  data  for  an  end  item,  hit  the  RETURN 
key  and  you  may  begin  entering  data  for  the  next  end  item. 

1  150. 

2  250. 

3  150. 

4  100. 

5  150. 

After  the  data  for  the  last  item  has  been  entered  and  the 
RETURN  key  hit,  ASOAR  asks  for  the  maintainability  data  of  each 
end  item.  The  END  ITEM  NUMBER  will  automatically  appear  and 
maintainability  information  corresponding  to  that  end  item  will 
need  to  be  inputted.  The  maintainability  inputs  required  for 
each  end  item  depends  on  the  response  previously  made  to  the 
list  of  maintainability  input  options. 

If  maintainability  input  Option  ”1”  was  selected,  the 
following  header  would  appear: 

END  ITEM  MEAN  TIME  TO  RESTORE 

NUMBER  FFF.FF 

1 

The  MEAN  TIME  TO  RESTORE  (MTR)  of  each  end  item  represents 
the  average  calendar  hours  per  failure  that  an  end  item  would  be 
down  if  LRU  spares  were  always  on-hand  to  restore  the  end  item. 
MTR  covers  both  the  designed  maintainability  of  the  end  item  and 
logistics  down  time  that  delays  restoral  time  despite  LRU  spares 
always  being  available. 


If  Option  "2"  was  selected,  the  following  header  would  appear. 

END  ITEM  MEAN  TIME  TO  REPAIR 

NUMBER  FEE .  EE  ••  ■*  “ 

1 

The  MEAN  TIME  TO  REPAIR  (MTTR)  of  each  end  item  r'"  :ese,its 
the  average  hours  per  failure  that  an  end  item  would  ,  down  if 
LRU  spares  are  always  on-hand  to  restore  the  end  iter  .n  an 
ideal  logistics  support  environment.  MTTR  is  the  de&.^ned 
maintainability  of  the  end  item. 

If  Option  "3"  was  selected,  the  following  header  would  appear: 

EI>TD  MEAN  TIME  ADDITIONAL  0R6  DOWNTIME 

ITEM  TO  REPAIR  PER  FAILURE 

NUMBER  FEF.FF  FFFF.FF 

1 

Option  "3"  is  similar  to  Option  “2"  except  additional 
restoral  time  per  failure  beyond  the  designed  MTTR  occurs.  The 
ADDITIONAL  ORG  DOWNTIME  PER  FAILURE  represents  the  average 
calendar  hours  per  failure  that  an  end  item  would  be  down  due  to 
logistics  factors  which  delays  restoral  time  despite  LRU  spares 
always  being  available.  These  logistics  factors  may  account  for 
obtaining  on-hand  LRU  spares  from  storage,  not  always  having 
appropriately  educated  or  skilled  personnel  available,  lack  of 
complete  or  correctly  written  maintenance  procedures  in  the 
Organizational  Level  technical  manuals,  and  not  always  having 
functioning  tools  or  test  equipment  available  with  the 
equipment . 

Type  in  the  following  MTR  input  data  associated  to  choosing 
maintainability  input  option  1  in  our  excunple.  When  you  finish 
entering  the  data  for  an  end  item,  hit  the  RETURN  key  and  you 
may  begin  entering  data  for  the  next  end  item. 

1  1.25 

2  1.5 

3  1. 

4  .5 

5  1. 

After  the  data  for  the  last  end  item  has  been  entered  and 
the  RETURN  key  hit,  ASOAR  asks  for  data  on  whether  the  Mean  Time 
To  Obtain  (MTTO)  LRU  spares  is  the  same  or  different  for  each 
end  item  within  the  system.  The  MTTO  represents  the  average 
time  it  takes  the  most  for"ard  level  of  suoply  support  to 
receive  LRU  spares  when  needed. 


9 


IS  THE  MEAN  TIME  TO  OBTAIN  (MTTO)  liRU  SPARES  TO  BE 

THE  SAME  INPUT  VALUE  FOR  ALL  END  ITEMS?  (Y/N) 

If  the  response  is  "N, "  ASOAR  will  prompt  for  an  MTTO  value 
for  each  end  item.  If  the  response  is  "Y",  all  the  end  items 
will  have  the  same  MTTO  value.  For  this  exercise,  all  the  end 
items  will  have  the  same  inputted  MTTO  value,  so  type  "Y"  and 
hit  the  RETURN  key.  The  list  of  supply  support  combination 
codes  then  follows: 

ENTER  LRU  SUPPLY  SUPPORT  COMBINATION  CODE, (1-7) 

1)  0R6,  DS,  6S,  DEP 

2)  ORG,  DS,  DEP 

3)  ORG,  GS,  DEP 

4)  ORG,  DEP 

5)  DS,  GS,  DEP  (USED  WITH  SPECIAL  CASE  8  OR  9) 

6)  DS,  DEP  (USED  WITH  SPECU^  CASE  8  OR  9) 

7)  GS,  DEP  (USED  WITH  SPECIAL  CASE  10) 

ENTER  CODE: 

The  support  levels  shown  in  choice  1  represents  the  four 
level  supply  chain  used  by  the  Army.  They  are  the 
Organizational  (ORG),  Direct  Support  (DS),  General  Support  (GS), 
and  Depot  (DEP)  levels.  Other  code  choices,  however,  allow  for 
a  sparing  scheme  that  does  not  employ  all  of  the  levels. 

Choices  1  through  4  have  the  ORG  level  as  the  most  forward 
level  of  LRU  spare  location.  Choices  5  thru  7  have  either  the 
DS  or  GS  as  the  most  forward  level  of  LRU  spare  location. 

Choices  5  thru  7  also  require  the  appropriate  special  case  to  be 
used  with  the  chosen  code.  Information  on  special  cases  8,  9, 
and  10  may  be  found  in  CHAPTER  4  under  their  respective 
sections.  For  our  example,  type  "1"  for  the  supply  support 
combination  code  and  hit  the  RETURN  key. 

ENTER  MTTO  INPUT  CODE  (1,2) 

1)  MEAN  TIME  TO  OBTAIN  (MTTO)  IS  AVAILABLE  FOR  INPUT 

2)  MEAN  TIME  TO  OBTAIN  (MTTO)  IS  TO  BE  COMPUTED 

ENTER  CODE: 

If  Option  "1"  is  used,  the  MEAN  TIME  TO  OBTAIN  (MTTO) 
value(s)  will  be  directly  inputted.  The  previous  supply  support 
combination  code  input  screen  appeared  for  informational 
puzposes . 
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If  Option  "2"  is  used,  the  MTTO  value(s)  will  be  computed 
based  on  additional  supply  support  and  maintenance  information. 
The  previous  supply  support  combination  code  input  will  become 
important  in  eliminating  unnecessary  supply  sunoort  and 
maintenance  information  inputs.  Option  "2"  . 

completely  in  CHAPTER  3  of  this  manual.  For  the  exercise,  type 
"1"  and  hit  the  RETURN  key. 


ENTER  HTTO  ( IN  HOURS )  FOR  LRU  SPARES  AT  MOST 

FORWARD  LEVEL  OF  SUPPORT 

FFFFF.FF 

The  units  for  MTTO  are  to  be  in  calendar  hours.  For  this 
exercise,  type  "48.”  and  hit  the  RETURN  key. 

The  table  below  is  what  appears  to  the  user.  It  shows  the 
entered  input  data  for  the  end  items.  If  errors  are  present, 
the  user  may  restart  the  program  from  the  beginning  or  modify 
the  data  file.  CHAPTER  8  explains  data  file  creation  and 
modification.  Either  choice  would  first  require  termination  of 
the  current  ASOAR  run. 

THE  FOLLOWING  IS  THE  DATA  BASE  FOR  TEST1.DAT. 

HIT  THE  ENTER  KEY  TO  SEE  EACH  ENTRY. 


END  END 

ITEM  ITEM 
NAME  NUMBER 

Iteml  1 

MEAN  CALENDAR  TIME 
BETWEEN  FAILURES 
150. 


END  END 

ITEM  ITEM 
NAME  NUMBER 

ltem2  2 


LOW  FAILURE 
END  HIGH  COST 

ITEM  ASSEMBLY 

COST  ESPENSE 

5000.  0. 

MEAN  TIME 
TO  RESTORE 
1.25 


LOW  FAILURE 
END  HIGH  COST 

ITEM  ASSEMBLY 

COST  EXPENSE 

4000.  0. 


MB2UI  CALENDAR  TIME 
BETWEEN  FAILURES 
250. 


MEAN  TIME 
TO  RESTORE 
1.50 
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END 

END 

END 

LOW  FiaLURE 
HIGH  COST 

ITEM 

ITEM 

ITEM 

ASSEMBLY 

NAME 

NUMBER 

COST 

EXPENSE. 

items 

3 

1000. 

0. 

HE2\N  CALENDAR  TIME  MEAN  TIME 

BETWEEN  FAILURES  TO  RESTORE 

150.  1.00 


LOW  FAILURE 


END 

END 

END 

HIGH  COST 

ITEM 

ITEM 

ITEM 

ASSEMBLY 

NAME 

NUMBER 

COST 

EXPENSE 

item4 

4 

2000. 

0. 

MEAN  CALENDAR  TIME  MEAN  TIME 

BETWEEN  FAILURES  TO  RESTORE 


100. 

• 

50 

LOW  FAIX.URE 

END 

END 

END 

HIGH  COST 

ITEM 

ITEM 

ITEM 

ASSEMBLY 

NAME 

NUMBER 

COST 

EXPENSE 

items 

5 

4000. 

0. 

MEAN  CALENDAR  TIME  MEAN  TIME 

BETWEEN  FAILURES  TO  RESTOKE 

150.  1.00 

At  the  end  of  the  input  table  is  the  question: 

ENTER  SYSTEM  OPERATIONAL  AVAILABILITY (Ao( SYS ) ) 

F.FFFF 

The  SYSTEM  OPERATIONAL  AVAILABILITY  (system  Ao)  represents 
the  probability  that  the  system  is  in  an  operable  or  committable 
condition  at  any  random  point  in  time.  It  represents  the 
percentage  of  calendar  time  that  the  equipment  is  up. 

Frequently,  the  desired  system  Ao  is  found  in  a  system 
requirements  dociment.  For  this  example,  type  ".93"  and  hit  the 
RETURN  key. 
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ARE  THERE  ANY  SPECIAL  CASES  INVOLVED ( Y/N ) ? 

If  "Y"  was  selected,  a  listing  of  the  10  special  cases  in 
ASOAR  would  follow.  CHAPTER  4  special  case  Inputs  and  Prompts 
deals  with  situations  where  the  special  cases  are  If  "N" 

is  selected,  ASOAR  computations  will  begin  which  should  lead  to 
an  output  of  results.  For  this  exercise  type  "N"  and  hit  the 
RETURN  key.  The  system  and  end  item  level  outputs  follow 
indicating  the  completion  of  the  ASOAR  model  run. 


SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  =  0.93000 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.93008 

MEAN  CALENDAR  TIME  BETH  FAILURES  (HRS)=  29.4 

SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  0.96 

SYSTEM  MEAN  LOGISTIC  DOHNTIME  (HRS)  =  1.188 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  =  0.9753 


HIT  ENTER  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUTS 


MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

RATE 

Iteml 

1 

150. 

1.25 

1.893 

0.97947 

0.9606 

item2 

2 

250. 

1.50 

2.524 

0.98416 

0.9474 

item3 

3 

150. 

1.00 

0.379 

0.99089 

0.9921 

item4 

4 

100. 

0.50 

0.505 

0.99005 

0.9895 

items 

5 

150. 

1.00 

1.515 

0.98351 

0.9684 

**************************************************************** 


NOTE:  ********  m  the  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASOAR  MODEL 
ASOAR  COMPLETED 
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CHAPTER  8.  ANALYSIS  OF  OUTPUT  TABLES"  explains  the  system  and 
end  item  level  output  results.  Essentially/  the  tables  say  that  the 
end  item  data  provided  by  the  user  allows  the  system  to  meet  the 
inputted  Ao  requirement  of  .93.  CHAPTER  7  explains  output  messages 
that  may  appear  instead  of  or  in  addition  to  the  tables. 
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CHAPTER  3.  COMPUTING  THE  MEAN  TIME  TO  OBTAIN  (MTTO)  SPARES 

The  most  forward  level  of  support's  Mean  Time  To  Obtain 
(MTTO)  LRU  spares  becomes  important  when  the  equij>ment  fails  and 
the  appropriate  LRU  is  not  stocked  forward  to  restore  the 
equipment.  The  MTTO  value  is  dependent  on  the  LRU  supply 
support  and  mair.cenance  concepts  being  considered.  The 
following  information  is  used  to  compute  MTTO. 

Data  required: 

-  LRU  Stock  Availability  (SA)  percentage  at  all  supply 
support  levels  except  the  most  forward  level  of  support. 

-  Order  and  Ship  Time  (OST)  in  days  between  support  levels. 

-  Percentage  of  LRUs  Not  Repaired  (PCTNREP)  or  returned  to 
stock. 

-  Percentage  of  LRUs  Repaired  (PCTREP)  at  various 
maintenance  support  levels. 

-  Average  Repair  Cycle  Time  (RCT)  in  days  at  all 
maintenance  levels. 

-  Mean  Time  to  Obtain  a  Back  Order  (30MTT0) 
in  days  at  DEP. 

Inputs  to  the  above  data  is  optional  because  there  are 
default  values  for  the  variables.  If  the  user  chooses  to  accept 
the  default  values,  supplying  the  above  data  is  not  necessary. 

When  the  most  forward  level  of  supply  support's  MTTO  of  LRU 
spares  is  cemputed,  the  LRU  supply  support  combination  code 
previously  inputted  as  described  in  Chapter  2,  may  eliminate  the 
need  for  some  supply  support  and  maintenance  information.  For 
example,  if  LRU  supply  support  combination  code  "2"  was  used 
where  there  is  no  General  Support  (GS)  level,  information 
regarding  LRU  stock  availability  at  GS,  repair  cycle  time  at  GS, 
and  order  and  ship  times  from  Depot  to  GS  and  from  GS  to  DS  all 
become  unnecessary. 

Computation  of  the  MTTO  is  initiated  by  entering  a  MTTO 
input  code  of  "2"  to  the  question. 

ENTER  MTTO  INPUT  CODE  (1,2) 

1)  MEAN  TIME  TO  OBTAIN  (MTTO)  IS  AVAILABLE  FOR  INPUT 

2)  MEAN  TIME  TO  OBTAIN  (MTTO)  IS  TO  BE  COMPUTED 

ENTER  CODE:  2 
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The  supply  support  combination  code  chosen  earlier  by  the 
user  determines  which  data  values  are  needed  by  ASOAR  to 
properly  compute  the  MTTO.  After  the  MTTO  input  code  has  been 
entered  and  the  RETURN  key  hit,  the  following  message  appears t 

FOR  MTTO  C2M.CULATION,  YOU  CAN  EITHER  WORK  WITH  THE  SCREE 
OR  A  PILE. 

SHOULD  YOU  RDM  ANY  SENSITIVITY  ANALYSIS, 

RECOMMEND  CREATING  THE  FILE. 

FOR  THIS  ITEM,  USER  WISHES  TO  WORK  WITH 

1)  EXISTING/NEW  FILES 

2)  THE  SCREEN  WITHOUT  SAVING  DATA 
ENTER  THE  CODE  1  OR  2: 

If  the  user  wishes  to  save  the  MTTO  data  or  to  use  already 
existing  files,  the  code  1  should  be  selected.  Each  end  item 
will  have  a  separate  MTTO  data  file.  For  the  items  which  share 
the  same  data,  the  identical  MTTO  data  file  can  be  recalled 
without  creating  separate  files.  If  the  code  1  is  entered, 

ASOAR  will  ask  the  user  to  input  the  file  name.  After  the  file 
name  is  given,  the  user  should  respond  "Y"  or  "N"  to  the  prompt 
asking  if  the  file  will  be  created  from  the  keyboard.  For  this 
exercise,  enter  "1". 

ENTER  MTTO  DATA  PILE  NAME: 

Now  type  MTTO.DAT. 

WILL  USER  ENTER  DATA  FROM  KEY  BOARD  (Y/N)? 

If  the  user  inputs  "N",  ASOAR  will  show  the  contents  of  the 
existing  file.  The  following  is  a  example. 

LRU  STOCK  AVAILABILITIES  AT  DS,  GS,  AND  DEPOT  LEVELS  ARE 
0.9500  0.9500  0.8500  RESPECTIVELY. 

ORDER  AND  SHIP  TIMES  FROM  DS  TO  ORG,  FROM  GS  TO  DS  AND  FROM 
DEPOT  TO  GS  TUIE  48.0  720.0  720.0  HOURS  RESPECTIVELY. 

PERCENTAGE  OF  LRUS  NOT  REPAIRED  OR  RETURNED  TO  STOCK  IS  0.1500 

PERCENTAGES  REPAIRED  AT  ORG,  DS,  GS,  AND  DEPOT  LEVELS  ARE 
0.0000  0.0000  0.0000  0.8500  RESPECTIVELY. 

AVERAGE  REPAIR  CYCLE  TIMES  AT  ORG,  DS,  GS,  AND  DEPOT  LEVELS  ARE 
0.0  0.0  0.0  1800.0  HOURS  RESPECTIVELY. 

MEAN  TIME  TO  OBTAIN  BACKORDER  AT  DEPOT  IS  2880.0  HOURS. 


Press  Enter  to  Continue. 
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Since  MTTO.DAT  does  not  exit,  type  ”Y"  to  create  the  file. 
As  the  user  goes  through  the  following  instruction,  the  file 
MTTO.DAT  will  be  created.  Now  ASOAR  will  lead  you  to  the 
following  message. 

TO  COMPUTE  THE  MTTO  CORRESPONDING  TO  THE  CHOSEN  SUPPLY 

SUPPORT  COMBINATION  CODE,  INDICATE  WHETHER  THE  DEFAULT 

VALUES  FOR  THE  FOLLOWING  INFORMATION  IS  ACCEPTABLE 

(Y=ACCEPTABLE,  N=NOT  ACCEPTABLE): 

Data  on  LRU  Stock  Availability  (SA)  is  prompted  for  first. 
The  SA  at  a  particular  support  level  is  the  percentage  of  time 
the  needed  LRU  is  at  that  level  when  a  demand  for  an  LRU 
occurs.  If  it  is  not  at  that  level,  the  LRU  is  obtained  from 
the  next  level  back  in  the  supply  chain,  which  has  its  own 
percentage  of  availability.  The  last  question  that  the  user 
supplies  data  for  (or  accepts  the  default  value)  is  the  prompt 
for  the  BOMTTO  at  DEP.  If  the  LRU  is  not  available  at  any 
level,  this  number  represents  the  average  time  it  takes  to  get 
the  LRU  to  the  DEP  level  and  hence  into  the  supply  chain  when 
needed . 

LRU  STOCK  AVAILABILITY  AT  DS  LEVEL  IS  .95  (Y/N): 

Type  "Y"  and  hit  the  RETURN  key. 

LRU  STOCK  AVAILABILITY  AT  GS  LEVEL  IS  .95  (T/N) : 

Type  "N,"  to  enter  a  value  different  from  the  default  value, 
and  hit  the  RETURN  key. 

ENTER  NEW  VALUE: 

.FFFF 

Type  ".90"  and  hit  the  RETURN  key. 

LRU  STOCK  AVAILABILITY  AT  DEPOT  LEVEL  1  IS  .85  (Y/N): 

Type  "Y"  and  hit  the  RETURN  key.  The  '|tiext  set  of  questions 
are  on  OST  between  the  levels  in  the  chosen  supply  support 
code.  It  is  the  time  from  the  need  to  place  a  requisition  until 
receipt  of  the  requisition  and  placement  o^  the  order  in  stock. 

ORDER  AMD  SHIP  TIME  FROM  DEPOT  TO  GS  IS^  30  DAYS  (Y/N) : 

Type  "Y"  and  hit  the  RETURN  key.  1 
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ORDER  AND  SHIP  TIME  FROM  GS  TO  DS  IS  30  DAYS  (Y/N)  : 

Type  "Y"  and  hit  the  RETURN  key. 

ORDER  AND  SHIP  TIME  FROM  DS  TO  ORG  IS  2  DAYS  (Y/N)  : 

Type  "Y"  and  hit  the  RETURN  key.  The  next  set  of  questions 
concern  the  PCTREP  or  percentage  repaired  at  appropriate  support 
levels.  The  first  prompt  asks  for  the  PCTNREP  or  percentage  not 
repaired  and  returned  to  stock  due  to  washout  of  the  LRUs,  the 
user  not  returning  LRUs  for  repair,  and  loss  of  the  LRtJs  in 
shipment . 

PERCENTAGE  OF  LRUS  NOT  REPAIRED  OR  RETURNED 

TO  STOCK  IS  .15  (Y/N): 

Type  "Y"  and  hit  the  RETURN  key. 

THE  PERCENTAGE  OF  LRUS  ABLE  TO  BE  REPAIRED  MOST  THEREFORE 

NOT  EXCEED  .8500.  WHEN  THAT  VALUE  IS  REACHED,  ANY  REMAINING 

SUPPORT  LEVELS  WILL  HAVE  A  0.00  PERCENTAGE  OF  LRUS  ABLE  TO 

BE  REPAIRED. 

PERCENTAGE  REPAIRED  AT  DEPOT  LEVEL  IS  .8500  (Y/N): 

All  of  the  support  levels  may  have  a  certain  PCTREP  at  their 
location.  The  total  of  all  repair  percentages  and  percentage 
not  repaired  or  returned  sums  to  one.  The  first  LRU  prompt 
allows  the  user  to  input  a  value  or  accept  the  default  value  for 
PCTNREP.  This  percentage  is  subtracted  from  1.00  and  the 
remaining  percentage  represents  the  maximum  amount  of  LRUs  that 
can  be  repaired  or  returned  to  stock.  Thus,  for  this  example, 
the  sum  of  the  PCTREP  from  all  levels  must  not  exceed  .8500. 

ASOAR  assigns  the  maximum  allowable  percentage  to  the 
default  value  of  the  DEP  level  (.8500).  If  the  user  accepts 
this  value,  then  the  percentage  repaired  at  the  remaining  levels 
(GS,  DS,  ORG)  will  be  zero.  Type  "N"  and  hit  the  RETURN  key. 

EXfTER  NEW  VALUE: 

.FFFF 


Type  ".8"  and  hit  the  RETURN  key. 

PERCENTAGE  REPAIRED  AT  GS  LEVEL  IS  .0500  (Y/N): 

Notice  that  ASOAR  has  calculated  a  new  maximum  default  value 
of  .0500  {1.-.15-.80)  for  the  next  level  of  support.  Type  "N" 
and  hit  the  RETURN  key. 

ENTER  NEW  VALUE 
.FFFF 
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Type  ".045"  and  hit  the  RETURN  key. 

PERCENTAGE  REPAIRED  AT  DS  LEVEL  IS  .0050  (Y/N) : 

Type  "Y"  and  hit  the  RETURN  key.  The  PCTREP 'at  the  ORG 
level  now  defaults  to  .0000  (since  the  maximum  value  was 
accepted  for  the  DS  level ) . 

ASOAR  then  asks  for  data  on  the  average  Repair  Cycle  Time 
(RCT)  at  the  support  levels.  This  is  the  average  time  from 
failure  that  it  takes  for  repair  of  an  LRU  to  occur  at  the 
particular  support  level.  It  includes  the  tine  from  when  the 
LRU  is  removed  from  the  end  item,  shipped,  screened/repaired, 
and  put  back  into  stock  at  the  support  level.  If  a  support 
level  has  a  zero  PCTREP  there,  then  the  corresponding  question 
for  the  average  RCT  at  that  support  level  will  not  be  asked. 

For  example,  since  there  was  a  zero  PCTREP  at  the  ORG  level  for 
this  exercise,  the  question  for  the  average  RCT  at  the  ORG  level 
will  not  be  asked. 

AVERAGE  REPAIR  CYCLE  TIME  AT  DEPOT  LEVEL  IS  75  DAYS  (Y/N): 

Type  "Y"  and  hit  the  RETURN  key. 

AVERAGE  REPAIR  CYCLE  TIME  AT  GS  LEVEL  IS  30  DAYS  (Y/N): 

Type  "Y"  and  hit  the  RETURN  key. 

AVERAGE  REPAIR  CYCLE  TIME  AT  DS  LEVEL  IS  2  DAYS  (Y/N): 

Type  "N"  and  hit  the  RETURN  key. 

ENTER  NEW  VALUE  ( IN  DAYS ) : 

FFFF.FF 

Type  "6."  and  hit  the  RETURN  key.  ASOAR  then  prompts  for 
data  concerning  the  average  time  it  takes  for  the  Depot  level  to 
obtain  a  backorder. 

MEAN  TIME  TO  OBTAIN  BACKORDER  AT  DEPOT  IS  120  DAYS  (Y/N)? 

Type  "Y"  and  hit  the  RETURN  key.  ASOAR  now  has  all  the 
information  necessary  to  compute  the  MTTO. 

*****  COMPUTED  VALUE  OF  MTTO  =  88.79  HRS  ***** 


The  computation  of  the  MTTO  is  complete  and  ASOAR  now 
returns  the  user  to  the  point  in  the  program  where  data  in  the 
failure  data  file  appears  on  the  screen  before  the  system  Ac, 
input  is  requested  as  shown  in  CHAPTER  2.  GETTING  STARTED:  A 
SAMPLE  RUN. 

THE  FOLLOWING  IS  THE  DATA  BASE  FCR  TEST1.DAT 
HIT  THE  RETURN  KEY  TO  SEE  EACH  ENTRY. 


CH2VPTER  4.  SPECIAL  CASE  INPUTS  AND  PROMPTS 


ASOAR  has  10  special  cases  to  handle  equipment 
commonalities,  equipment  redundancies,  scheduled  maintenance  or 
periodic  startup  causing  downtime,  multiple  systems  per  site, 
and  systems  with  end  item  spares,  and  systems  without  LRUs 
stocked  forward  at  the  operating  level. 

The  prompt  for  the  special  cases  appears  after  the  following 
question  about  the  system  operational  availability  is  answered. 

ENTER  SYSTEM  OPERATIONAL  AVAILABILITy(AO(STS)  ) 

F.FFFF 

For  our  examples,  ".93"  was  answered. 

ARE  THERE  ANY  SPECIAL  CASES  INVOLVED ( Y/N ) ? 

A  response  of  "Y"  will  produce  the  special  cases  menu.  Type 
"Y"  and  hit  the  RETURN  key. 

CASE  1:  SERIALLY  CONFIGURED  COMMON  END  ITEMS 
CASE  2:  HOT  STANDBY  REDUNDANT  END  ITEMS 

CASE  3:  COLD  STANDBY  REDUNDANCY  OR  END  ITEM  SPARES  WITH  SYSTEM 

CASE  4:  DEGRADATIONAL  REDUNDANCY  OR  CAPACITY  AVAILABILITY 

CASE  5:  SYSTEM  SCHEDULED  MAINTENANCE  OR  PERIODIC  STARTUP 
CAUSING  DOWNTIME 

CASE  6:  END  ITEM  SCHEDULED  MAINTENANCE  OR  PERIODIC  STARTUP 
CAUSING  SYSTEM  DOWNTIME 

CASE  7:  MULTIPLE  SYSTEMS  RESTORED  WITH  LRU  SPARES  AT  ORG  LEVEL 

CASE  8:  SYSTEMS  RESTORED  WITH  LRUS  STOCKED  FORWARD  AT  DS  LEVEL 

CASE  9:  SYSTEMS  RESTORED  WITH  END  ITEM  AMD  LRUS  STOCKED  FORWARD 
AT  DS  LEVEL 

CASE  10:  SYSTEMS  RESTORED  WITH  END  ITEM  SPARES  AT  DS  AND  LRUS 
STOCKED  FORWARD  AT  GS  LEVEL 


ENTER  CASE  NDMBER(1,2,3 _ ,10) 

At  this  point  the  user  selects  the  desired  case. 
Information  and  data  required  for  each  case  is  provided  in  the 
remainder  of  this  section. 


CASE  1;  RBRTAT.T.Y  CONFIGURED  COMMON  EMD  ITEMS 


Dcl'ta.  Required  —  the  item  number  v  -n..  — ii  which  is 

common;  the  quantity  of  the  common  end  item(s). 

A  common  end  item  is  an  end  item  that  appears  in  more  th  i 
once  in  the  system.  CASE  1  is  concerned  with  commonality  1:  in 

a  series  configuration  as  opposed  to  the  common  end  items  b  -ng 
in  parallel.  For  example,  FIGURE  1  shows  a  portion  of  a 
possible  system  configuration.  End  Item  1  is  common  in  a  serial 
manner  and  End  Item  2  is  common  in  a  parallel  manner.  The 
distinction  is  important  because  if  one  of  the  end  items  of  End 
Item  2  goes  down,  the  system  may  still  be  up.  However,  if  one 
of  the  end  items  of  End  Item  1  goes  down,  then  the  system  goes 
down . 


FIGURE  1 


lei  2! 

o - |ei"I| - j’  I - |ei  1! - lei  3| - |ei  4| - o 

jel’Sl 


After  CASE  "1"  has  been  entered,  the  user  is  prompted  for 
the  number  of  end  items  which  are  in  this  category. 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

HOW  MANY  DIFFERENT  END  ITEMS  ARE  IN  THIS  CATEGORT? 

II 


Two  of  the  5  end  items  in  the  file  TEST1.DAT  will  be  used  as 
common  for  this  exercise.  Type  "02"  and  hit  the  RETtJRN  key. 

1  -  dc 


CASE 


ZOMMON  END  ITEMS  (SERIAL  END  ITEM) 


ITEM  NUMBER 
II 


QUANTITY 

III 
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Type  in  the  following  data  under  the  appropriate  column 
headings  using  the  space  bar  and  backspace  key  to  move  between 
fields .  When  you  are  finished  entering  the  data  for  an  end 
item,  hit  the  RETURN  key  and  you  may  then  begin  entering  data 
for  the  next  end  item. 

12 
3  2 

The  system  now  consists  of  7  end  items;  2  end  items  of  type 
iteml,  2  end  items  of  type  item3,  and  1  end  item  each  of  the 
other  end  items. 

When  the  data  for  the  last  end  item  is  entered  and  the 
RETURN  key  hit,  ASOAR  asks  whether  any  other  cases  are  to  be 
used  for  this  system. 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED(  Y/N)  ? 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear : 


SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  =  0.93000 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.93004 

MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  21.1 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  1.01 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  0.538 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  »  0.9888 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 

y 

y  MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

Ao  of  1 

RATE 

Iteml 

1 

75. 

1.25 

0.597 

0.97597 

0.98791 

0.9876 

ltem2 

2 

250. 

1.50 

1.591 

0.98779 

0.9668 

ltem3 

3 

75. 

1.00 

0.119 

0.98529 

0.99262 

0.9975 

item4 

4 

100. 

0.50 

0.318 

0.99188 

0.9934 

items 

5 

150. 

1.00 

0.955 

0.98714 

0.9801 

A********************************-****-*************************** 

NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASQAR  MODEL 


ASOAR  COMPLETED 


i 

/ 
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CASE  2;  HOT  STANDBY  REDUNDANT  END  ITEMS 


Data  Required  -  the  name  and  item  number  of  the  end  item 
which  is  redundant;  the  total  quantity  of  the  end  item  and 
how  many  of  that  quantity  are  needed  for  the  system  to  be 
up . 

Redundancy  is  used  to  describe  a  situation  where  there  are 
more  end  items  present  than  actually  are  needed.  That  is,  a 
certain  number  of  end  items  are  required  for  the  system  to  be 
fully  up  and  the  other  end  items  can  be  considered  extra.  The 
phrase  "hot"  standby  means  that  when  one  of  the  required  end 
items  goes  down  and  there  is  a  similar  end  item  operating  in  a 
standby  mode,  control  is  passed  to  that  extra  end  item  almost 
instantaneously.  This  means  that  practically  no  addition?! 
downtime  occurs  during  this  switch  and  that  the  system  remains 
fully  up.  Since  the  extra  end  item  must  be  kept  operating  or 
"up"  for  this  near  instantaneous  switch  to  occur,  it  fails  more 
frequently  than  not  operating.  If  it  should  take  a  significant 
cimount  of  time  to  pass  control  or  switch  to  hot  standby 
redundant  end  items,  then  CASE  6.  END  ITEM  SCHEDULED 
MAINTENANCE  OR  PERIODIC  STARTUP  CAUSING  SYSTEM  DOWNTIME  can  be 
used  to  handle  this  additional  downtime. 

After  CASE  "2"  has  been  entered,  the  user  is  prompted  for 
the  filename  which  contains  the  hot  standby  redundancy  data. 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

SHOULD  THERE  BE  ANT  INPUT  MISTAKE  WHICH  CANNOT  BE  CORRECTED, 
YOUR  INPUT  FILE  CAN  BE  MODIFIED  AFTER  THIS  PROGRAM  RUN. 


ENTER  HOT  REDUNDANCY  DATA  FILE  NAME: 

Type  "CASE2.DAT"  and  hit  the  RETURN  key. 

WILL  USER  ENTER  REDUNDANCY  DATA  FROM  KEYBOARD  (T/N)? 

If  the  response  "N"  is  typed,  ASOAR  searches  for  the 
redundancy  data  in  the  file  CASE2.DAT.  Since  this  file  does  not 
yet  exist,  the  data  must  be  entered  from  the  keyboard.  Type  "Y" 
and  hit  the  RETURN  key. 
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The  data  from  the  keyboard  will  be  atored  in  the  file 
CASE2.DAT.  ASOAR  will  lead  the  user  through  the  following 
prompts . 

HOW  MANY  DIFFERENT  END  ITEMS  ARE  IN  TEI^  " ' 

II 

Three  of  the  5  end  items  in  the  file  TEST1.DAT  will  be  us  i 
in  this  excimple.  Type  "3"  and  hit  the  RETURN  key. 

CASE  2  -  HOT  STANDBY  REDUNDANT  END  ITEMS 

ITEM  ITEM 

NAME  NO.  R  OF  N 

AAAAAAAA  II  II  II 

For  the  given  end  item,  the  header  "R  OF  N"  says  that  out 
of  the  "N"  similar  end  items,  "R“  of  them  are  required.  The 
remaining  end  items,  N-R  of  them,  are  c  *nsidt.red  redundant. 
Instances  where  R  equals  N  yields  result's  similar  to  CASE  1. 
SERIALLY  CONFIGURED  COMMON  END  ITEMS. 

Enter  the  following  data.  Use  the  space  bar  and  backspace 
key  to  move  between  fields .  Hit  the  RETURN  key  to  enter  data 
for  the  next  end  item. 


Iteml 

03 

02 

07 

ltem2 

02 

01 

02 

item3 

03 

01 

02 

When  the  data  for  the  last  end  item  is  entered  and  the 
RETURN  key  hit,  ASOAR  asks  whether  any  other  cases  are  to  be 
used  for  this  system. 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED  ( Y/N )  ? 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear. 
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SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL 
ADJUSTED  OPERATIONAL  AVAIL  GOAL 
END  ITEM  OPERATIONAL  AVAIL  PRODUCT 


=  0.93000 
=  0.93000 
=  0.92997 


MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)  = 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS) 

SYSTEM  ME2^  LOGISTIC  DOWNTIME  (HRS) 
SYSTEM  ORDER  FILL  RATE  OF  LRUS 


55.2 

0.74 

3.306 

0.9017 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 

MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

Ao  of  1 

RATE 

iteml 

1 

19234. 

1.25 

6.958 

0.99957 

0.79515 

0.0000 

itein2 

2 

1509. 

1.50 

23.250 

0.98387 

0.87298 

O.OOOO 

ltem3 

3 

1337. 

1.00 

8.464 

0.99297 

0.91618 

0.6265 

item4 

4 

100. 

0.50 

1.261 

0.98269 

0.9737 

items 

5 

150. 

1.00 

3.784 

0.96909 

0.9212 

**************************************************************** 


NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASOAR  MODEL 


ASOAR  CO!{PLETED 


CASE  3;  COLD  STANDBY  REDUNDANCY  OR  END  ITEM  SPARES  WITH  SYSTEli 


Data  Required  -  the  ricune  and  item  of  -the  end  itei 

which  is  redundant;  the  rotal  qua..  cn>i  end  item  i 

how  many  of  that  quantity  are  needed  for  the  system  to 
considered  up;  unscheduled  maintenance  downtimes  (hour 
associated  with  the  redundant  end  items. 

The  redundancy  that  exists  in  CASE  3  is  similar  to  th 
redundancy  that  exists  in  CASE  2  with  a  major  difference  The 
switch  to  the  redundant  end  item  when  the  required  end  .  .i  goes 
down  is  not  an  instantaneous  switch.  Although  available  che 
cold  standby  redundant  end  item  is  not  up  or  operating.  There  is 
some  unscheduled  maintenance  downtime  reqtiired  to  pass  t:ontrol  or 
switch  to  the  redundant  end  item  and  to  bring  it  to  an  operating 
condition.  The  system  is  down  during  this  unscheduled  downtime. 
However,  while  there  is  additional  downtime  present  in  the 
system,  the  redundant  end  item  is  not  accruing  failure  hours  in 
its  cold  standby  mode  because  it  is  not  operating  until  it  is 
needed.  Redundant  end  items  in  the  hot  standby  mode  do  accrue 
failure  hours  because  they  ire  operating  when  not  needed. 

After  CASE  "3"  has  been  entered,  the  user  is  prompted  for  the 
filename  which  contains  the  cold  standby  redundancy  data. 

CASE  3  -  COLD  STANDBY  REDUNDANCY  OR  END  ITEM  SPARES  WITH  SYSTEM 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

SHOULD  THERE  BE  ANY  INPUT  MISTAKE  WHICH  CANNOT  BE  CORRECTED, 
YOUR  INPUT  FILE  CAN  BE  MODIFIED  AFTER  THIS  PROGRAM  RUN. 

ENTER  COLD  REDUNDANCY  DATA  FILE  NAME: 

The  user  can  either  create  a  new  file  or  use  an  existing  file 
previously  created.  Type  "CASE3.DAT"  and  hit  the  RETURN  key. 

WILL  USER  ENTER  REDUNCANCY  DATA  FROM  KEYBOARD  (Y/N)? 

If  the  response  "N"  is  typed,  ASOAR  searches  for  the 
redundancy  data  in  file  CASE3.DAT.  Since  this  file  does  not  yet 
exist,  the  data  must  be  entered  from  the  keyboard.  Type  "Y"  and 
hit  the  RETURN  key.  The  data  from  the  keyboard  will  be  stored  in 
the  file  CASE3.DAT. 
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ASOAR  will  now  prompt  the  user  for  cold  standby  redundancy 
data.  This  data  covers  unscheduled  maintenance  downtime 
associated  to  switching  over  to  a  redundant  or  spare  end  item. 
This  data  also  provides  system  configuration  information 
regarding  the  number  of  similar  end  items  operating  for  the 
system  to  be  up  and  the  total  number  of  similar  end  items 
available  with  the  system. 

HOW  MANY  DIFFERENT  END  ITEMS  ARE  IN  THIS  CATEGORY? 

II 

Three  of  the  5  end  items  in  the  file  TEST1.DAT  will  be  used 
in  this  example.  Type  "3"  and  hit  the  RETURN  key. 

ITEM  ITEM  MEAN  MAINTENANCE 

NAME  NUMBER  DOWNTIME  R  OF  N 

AAAAAAAA  II  FF.FF  II  II 

Each  end  item  in  cold  standby  redundancy  has  unscheduled 
maintenance  downtime  associated  with  it.  This  downtime 
represents  the  switch  over  time  to  a  redundant  end  item  or  end 
item  spare . 

For  the  given  end  item,  the  header  "R  OF  N"  says  that  out  of 
the  "N"  similar  end  items,  "R"  of  them  are  required.  The 
remaining  end  items,  N-R  of  them,  are  considered  redundant. 
Instances  where  R  equals  N  are  handled  by  either  CASE  1.  COMMON 
END  ITEMS  or  CASE  4.  DEGRADATIONAL  REDUNDANCY. 

Enter  the  following  data.  Use  the  space  bar  and  backspace 
key  to  move  between  fields.  Hit  the  RETURN  key  to  enter  data  for 
the  next  end  item. 


iteml 

01 

.50 

02 

07 

item? 

02 

.25 

01 

02 

item3 

03 

1.50 

01 

02 

When  the  data  for  the  last  end  item  is  entered  and  the  RETURN 
key  hit,  ASOAR  asks  whether  any  other  cases  are  to  be  used  for 
this  system. 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED  (Y/N)? 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear : 


SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

AHruSTED  OPERATIONAL  AVAIL  GOAL  =  0.94651 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.94656 

KEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  57.2 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  0.72 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  2.446 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  *  0.9322 


HIT  RETURN  TO  SEE  END  ITLM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

Ao  of  1 

RATE 

iteml 

1 

774369. 

1.25 

6.958 

0.99999 

0.89048 

0.0000 

item2 

2 

2854. 

1.50 

23.250 

0.99140 

0.90727 

0.0000 

ltem3 

3 

2144. 

1.00 

10.562 

0.99464 

0.92675 

0.5391 

item4 

4 

100. 

0.50 

0.989 

0.98533 

0.9794 

item5 

5 

150. 

1.00 

2.968 

0.97423 

0.9382 

*************iHt**1i*1i*****it****1t1Ht***1Ht****1t1t1t***1t1t*****1t*1i*****1t 

NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASQAR  MODEL 


ASQAR  COMPLETED 


CASE  4;  DEGRADATIONAL  REDUNDANCY  OR  CAPACIT7  AVAILABILITY 


Data  Required  -  the  name  and  item  number  of  the 
end  item  which  is  redunda:  t;  the  total  quantity  of  the  end 
items  needed  for  the  system  to  be  fully  up  and  how  many  of 
that  quantity  are  operating  in  the  system;  unscheduled 
maintenance  downtimes  (hours)  associated  with  the  cold 
standby  degradational  redundant  end  items;  minimum  number  of 
end  items  for  the  system  to  be  considered  fully  up;  maximum 
number  of  end  items  for  the  system  to  be  considered  fully 
down;  the  percentage  of  upness  associated  to  states  where 
the  number  of  end  items  up  correspond  to  the  system  being 
neither  fully  up  nor  fully  down  (optional). 

Degradational  redundancy  or  capacity  availability  applies  to 
both  hot  standby  redundancy  and  cold  standby  redundancy  (CASES  2 
and  3).  In  fact,  when  the  user  chooses  CASE  4  as  the  special 
case  for  the  system,  the  first  question  asked  is  which  kind  of 
redundancy  applies  to  CASE  4 . 

CASE  4  -  DEGRADATIONAL  REDUNDANCY  OP  CAPACITY 
AVAILABILITY 

ENTER  THE  CODE  (1,2)  ASSOCIATED  ?/ITH  WHETHER 

THE  DEGRADATIONAL  REDUNDANCY  IS  A  HOT  OR  COLD  STANDBY 

REDUNDANCY. 

1) H0T  STANDBY  DEGRADATIONAL  REDUNDANCY 

2)  COLD  STANDBY  DEGRADATIONAL  REDUNDANCY 

ENTER  CODE: 

Many  of  the  questions  and  prompts  in  CASE  4  are  identical  to 
those  in  CASES  2  and  3  also.  For  this  reason,  the  user  is  asked 
to  review  the  previous  information  on  CASE  2  or  3,  whichever 
happens  to  apply  to  CASE  4  at  the  time,  for  a  more  detailed 
explanation  on  hot  and  cold  redundancies  in  general. 

Degradational  redundancy  is  used  to  describe  a  system  which 
is  operating  at  less  than  100%  capacity.  The  system  is  not 
operating  in  the  fuDly  up  mode,  but  at  a  level  that  is  a  certain 
percentage  of  the  fully  up  state.  In  other  words,  degradational 
redundancy  is  a  state  of  operation  of  the  system  between  the 
levels  of  fully  up  (100%)  and  fully  down  (0%). 

An  exaimple  may  best  illustrate  this  concept.  Consider  a 
system  with  6  end  items  of  type  A.  Out  of  the  6  end  items  of 
type  A,  the  system  needs  4  of  them  operating  to  be  considered 
fully  up.  The  other  2  end  items  of  type  A  are  redundant  in  the 


cold  standby  mode. 

The  4  end  items  of  type  A  would  be  the  minimum  number  of  end 
items  required  for  the  system  to  be  considered  fully  up.  If  the 
system  is  completely  down  when  only  1  end  item  of  type  A  is  left 
operating,  this  would  represent  the  maximum  number  of  end  items 
for  the  system  to  be  considered  fully  down.  If  1  of  the  4 
operating  end  items  were  to  go  down,  the  system  would  not  go 
down  but  may  operate  at  a  75%  capacity  with  the  3  remaining  end 
items  (until  one  of  the  redundant  end  items  would  bring  the 
system  back  up  to  fully  operational).  With  2  end  items  of  type 
A  operating,  the  system  may  be  operating  at  50%  capacity.  ASOAR 
will  ask  if  the  percent  capacity  or  upness  percentage  is  to  be 
inputted  directly  by  the  user.  For  this  example,  the  upness 
percentages  are  inputted.  If  the  upness  percentages  are  not 
inputted,  ASOAR  will  compute  values  internally.  A  linear 
approximation  is  used  for  this  computation  (66.7%  upness  with  3 
end  items  operating  and  33.3%  upness  with  2  end  items  operating 
for  this  example). 

CASE  4  will  now  be  examined  in  more  detail.  After  CASE  "4’* 
has  been  entered,  ASOAR  asks  the  user  to  choose  the  code 
corresponding  to  which  mode  of  redundancy  applies  to  the  system. 

ENTER  THE  CODE  (1,2)  ASSOCIATED  WITH  WHETHER 

THE  DE6RADATI0NAL  REDUNDANCY  IS  A  HOT  OR  COLD  STANDBY 

REDUNDANCY. 

1) HOT  STANDBY  DEGRADATIONAI,  REDUNDANCY 

2)  COLO  STANDBY  DEGRADATIONAL  REDUNDANCY 

I 

ENTER  CODE: 

Type  "1"  and  hit  the  RETURN  key. 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 

HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

SHOULD  THERE  BE  ANY  INPUT  MISTAKE  WHICH  CANNOT  BE  CORRECTED, 

YOUR  INPUT  FILE  CAN  BE  MODIFIED  AFTER  THIS  PROGRAM  RUN. 


ENTER  HOT  REDUNDANCY  DATA  FILE  NAME: 

If  the  code  for  cold  standby  degradational  redundancy  had 
been  entered,  the  first  question  would  have  been  for  the  Cold 
Redundancy  Data  File  name,  just  as  in  CASE  3.  Since  CASE2.DAT 
is  not  used  in  this  example  rtin,  type  "CASE4.DAT"  and  hit  the 
RETURN  key. 

WILL  USER  ENTER  REDUNDANCY  DATA  FROM  KEYBOARD  (Y/N)? 
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If  the  response  "N”  is  typed,  ASOAR  searches  for  the 
redundancy  data  in  the  file  CASE4.DAT.  Since  this  file  does  not 
yet  exist,  the  data  must  be  entered  from  the  keyboard.  Type  "Y" 
and  hit  the  RETURN  key.  The  data  from  the  keyboard  will  be 
stored  in  the  file  CASE4.DAT. 

HOW  MANY  DIFFERENT  END  ITEMS  ARE  IN  THIS  CATEGORY? 

II 

For  this  example,  2  of  the  5  end  items  in  TEST1.DAT  will 
have  degradational  r»'  iuadancy  associated  with  them.  Type  "02" 
and  hit  the  RETURN  k  ,  ASOAR  indicates  the  type  of 
degradational  redundai/...y,  either  CASE  2  or  CASE  3,  chosen  by  the 
user.  The  end  item  data  is  then  prompted  for: 

ITEM  ITEM 

NAME  NO.  R  OF  N 

AAAAAAAA  II  II  II 

For  the  given  end  item,  the  header  "R  OF  N"  may  say  that 
out  of  the  "N"  similar  end  items,  "R"  of  them  are  operating. 

Any  remaining  end  items,  N-R  of  them,  are  needed  for  full 
operation  but  considered  missing  from  the  system.  Note  that  the 
"R"  value  in  CASE  4  may  not  stand  for  "required"  as  in  CASES  2 
and  3.  This  is  because  there  may  exist  a  situation  where  all 
the  end  items  present  are  operating,  but  the  system  may  still 
not  be  fully  up.  For  example,  4  end  items  of  type  A  are 
available  and  all  of  them  are  operating,  but  6  end  items  of  type 
A  are  actually  needed  for  the  system  to  be  fully  up.  If  this 
situation  did  exist,  the  4  of  4  operating  end  items  would 
represent  a  degradational  state  of  the  system.  The  number  6 
would  then  represent  the  minimum  number  of  end  items  required 
for  the  system  to  be  considered  fully  up.  For  all  other 
situations  where  enough  end  items  are  within  the  system  to 
operate  at  full  capacity,  the  minimum  number  of  end  items 
required  for  the  system  to  be  considered  fully  up  is  equal  to 
"R. " 


Enter  the  following  data  for  the  first  end  item.  Use  the 
space  bar  and  the  backspace  key  to  move  between  fields.  Hit  the 
RETURN  key  when  the  data  is  finished  being  entered. 

iteml  01  03  04 

ASOAR  now  prompts  for  the  data  associated  with  the 
degradational  redundancy. 

ENTER  MINIMDM  NUMBER  OF  END  ITEMS 

OPERATIONAL  TO  BE  CONSIDERED  FULLY  UP 
II 
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As  was  mentioned  in  the  previous  page,  this  number  may  be 
equal  to  the  inputted  "R"  value  when  enough  end  items  are  within 
the  system  to  operate  at  full  capacity.  The  exception  would  be 
equal  to  the  "N"  value  if  the  R  value,  represented  a 
degradational  state.  Type  "3"  and  hit  the  .vZTURN  key. 

ENTER  MAXIMUM  NUMBER  OF  END  ITEMS 
OPERATIONAL  TO  BE  CONSIDERED  FULLY  DOWN 
(GENERALLY  ZERO) 

II 


While  a  value  of  zero  does  apply  to  most  end  items,  the  user 
may  input  a  value  up  to  and  including  R-1.  Type  "0"  and  hit  the 
RETURN  key.  ASOAR  now  asks  for  the  upness  percentages. 

ARE  UPNESS  PERCENTAGES  TO  BE  MANUALLY  ENTERED  (Y/N)? 

If  "N"  is  entered  as  the  response,  ASOAR  internally  computes 
the  upness  percentages  for  2  out  of  4  end  items  of  type  iteml 
operating  and  also  for  1  out  of  4  operating.  Column  headings 
would  then  appear  indicating  that  data  for  the  next  end  item  is 
to  be  entered.  Type  "Y"  and  hit  the  RETURN  key. 

ENTER  UPNESS  PERCENTAGE  FOR  2  OUT  OF  4  ITEMS  OPERATING 

(A  PERCENTAGE  IN  THE  RANGE  0-1) 

.FFFF 

Type  ".9"  and  hit  the  RETURN  key. 

ENTER  UPNESS  PERCENTAGE  FOR  1  OUT  OF  4  ITEMS  OPERATING 

(A  PERCENTAGE  IN  THE  RANGE  0-1) 

.FFFF 

Type  ”.75"  and  hit  the  RETURN  key.  The  column  header 
appears  indicating  that  data  for  the  next  end  item  is  to  be 
entered. 

ITEM  ITEM 

NAME  NO.  R  OF  N 

AAAAAAAA  II  II  II 

Enter  the  following  data  for  the  next  end  item. 

Item4  04  01  02 

After  the  RETURN  key  is  hit,  ASOAR  asks  for  the  minimum  and 
maximum  number  of  end  item  values  for  item4. 
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ENTER  MINIMDM  NUMBER  OF  END  ITEMS 

OPERATIONAL  TO  BE  CONSIDERED  FULLY  UP 
II 

Type  "1"  and  hit  the  RETURN  key. 

ENTER  MAXIMUM  NUMBER  OF  END  ITEMS 

OPERATIONAL  TO  BE  CONSIDERED  FULLY  DOWN 

(GENERALLY  ZERO) 

II 

Type  "0"  and  hit  the  RETURN  key.  ASOAR  does  not  ask  for 
upness  percentages  when  there  is  no  possibility  of  operation 
between  the  fully  up  and  fully  down  inodes.  For  item4  in  this 
example/  it  is  similar  to  using  CASE  2. 

When  the  data  for  the  last  end  item  is  entered  and  the 
RETURN  key  hit,  ASOAR  asks  whether  any  other  cases  are  to  be 
used  for  this  system. 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED (Y/N) 7 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears .  CHAPTER  5 .  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  ”N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear ; 


SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  =  0.93000 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.92994 

MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  51.8 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  1.09 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  2.710 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  =  0.9172 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME  NUMBER 

MCTBF 

MTR 

MLDT 

AO 

Ao  of  1 

RATE 

iteml 

1 

1194. 

1.25 

19.410 

0.98299 

0.82925 

0.1652 

ltem2 

2 

250. 

1.50 

3.279 

0.98124 

0.9317 

item3 

3 

150. 

1.00 

0.492 

0.99015 

0.9898 

iteia4 

4 

891. 

0.50 

5.816 

0.99296 

0.91609 

0.7472 

items 

5 

150. 

1.00 

1.967 

0.98060 

0.9590 

n*************************************************************** 


NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOUR 


THANK  YOU  FOR  USING  THE  ASOAR  MODEL 
ASOAR  COMPLETED 
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CASE  5;  SYSTEM  SCHEDULED  MAINTENANCE  OR  PERIODIC  ST2!JITUP 
CAUSING  DOWNTIME 


Data  Required  -  system  mean  calendar  time  between 
maintenance  (hours);  system  mean  maintenance  downtime 
( hours ) . 

ASOAR  allows  the  user  to  input  additional  downtime  when  the 
system  is  not  available  due  to  scheduled  maintenance  or  some 
other  foreseen  reason  causing  additional  periodic  downtime. 

This  additional  downtime  adjusts  the  system  Ao  requirement  so 
that  a  higher  A*,  goal  must  be  reached.  CASE  5  may  also  be 
used  more  than  once  during  an  ASOAR  run.  For  example,  a  system 
may  be  unavailable  for  4  hours  every  1000  hours  due  to 
preventive  maintenance  and  it  may  have  to  be  relocated  every 
5000  hours.  During  this  relocation  process,  the  system  may  be 
down  for  10  hours  due  to  tear  down  time,  movement  and  setup 
time . 

After  CASE  "5"  has  been  entered,  ASOAR  asks  for  the  time 
between  scheduled  maintenance  and  the  actual  amount  of  time  that 
the  system  is  down. 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 


CASE  5:  SYSTEM  SCHEDULED  MAINTENANCE  OR 

PERIODIC  STARTUP  CAUSING  DOWNTIME 


SYSTEM  MEAN 
CALENDAR  TIME 
BETWEEN 
MAINTENANCE 
FFFFF.FF 


SYSTEM  MEAN 
MAINTENANCE 
DOWNTIME 

FFF.FF 


The  Mean  Calendar  Time  Between  Maintenance  (MCTBM)  is  a 
measure  of  downtime  frequency.  It  says  that  additional  downtime 
occurs  every  x  number  of  hours.  The  Mean  Maintenance  Downtime 
(MMDT)  represents  the  actual  amount  of  downtime  associated  with 
a  maintenance  action.  Type  in  the  following  values  and  hit  the 
RETURN  key  when  finished. 

500.0  6.0 


When  the  data  for  the  end  item  is  entered  and  the  RETURN  key 
hit,  ASOAR  asks  whether  any  other  cases  are  to  be  used  for  this 
system. 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED ( Y/N ) ? 
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If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear: 


SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  -  0.94116 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.94121 

MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  29.4 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  0.96 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  0.833 

SYSTEM  ORDER  FILL  RATE  OF  UlUS  =  0.9826 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


MEAN  TIME  TO 

OBTAIN  (MTTO) 

FOR  EACH 

END  ITME: 

48.0 

ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

RATE 

iteml 

1 

150. 

1.25 

1.328 

0.98311 

0.9723 

item2 

2 

250. 

1.50 

1.770 

0.98709 

0.9631 

item3 

3 

150. 

1.00 

0.266 

0.99163 

0.9945 

ltem4 

4 

100. 

0.50 

0.354 

0.99153 

0.9926 

items 

5 

150. 

1.00 

1.062 

0.98644 

0.9779 

It*************************************************************** 


NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASOAR  MODEL 
ASOAR  COMPLETED 
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CASE  6i  END  ITEM  SCHEDULED  MAlNTEMfliNCE  OR  PERIODIC  STARTUP 
CAUSING  SYSTEM  DOWNTIME 


Data  Required  -  the  number  of  end  items  with  periodic 
maintenance  causing  system  downtime;  the  name  and  item 
number  of  the  end  item  with  periodic  maintenance;  end  item 
mean  calendar  time  between  maintenance  (hours);  end  item 
mean  maintenance  downtime  ( hours ) . 

CASE  6  allows  the  user  to  input  additional  do:«itime  when  an 
end  item  is  not  operational  and  causing  the  system  to  be  down. 
This  may  be  due  to  scheduled  maintenance,  hot  standby  redundancy 
switch  over  time  or  some  other  foreseen  reason  causing 
additional  periodic  downtime.  The  additional  downtime  in  CASE  6 
adjusts  the  system  Ao  requirement  so  that  a  higher  Ao  goal 
must  be  reached.  CASE  6  can  be  used  on  all  end  items  except  for 
those  that  are  usud  in  cold  standby  redundancy  (CASE  3)  and  cold 
degradational  redundancy  (CASE  4,  choice  2).  This  is  because 
CASE  6  is  already  incorporated  into  CASE  3  and  CASE  4(2)  via  the 
Mean  Calendar  Time  Between  Maintenance  being  computed  internally 
from  the  end  item  MCTBF  and  quantity  of  end  items  operating  for 
each  end  item  in  these  two  cases.  The  Mean  Maintenance  Downtime 
in  CASES  expresses  the  average  amount  of  both  end  item  and 
system  downtime  associated  to  the  maintenance  action  or  proiodic 
startup  of  the  end  item. 

After  CASE  "6"  has  been  entered,  ASOAR  asks  for  the  time 
between  scheduled  maintenance  and  the  actual  £uaount  of  time  that 
the  system  is  down. 

I 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

SHOULD  THERE  BE  ANY  INPUT  MISTAKE  NHICH  CANNOT  BE  CORRECTED, 
TOUR  INPUT  FILE  CAN  BE  MODIFIED  AFTER  THIS  PROOIAH  RUN. 


ENTER  MAINTENANCE  DOWNTIME  DATA  FILE  NAME: 

Type  "CASE6.DAT"  and  hit  the  RETURN  key. 

MILL  USER  ENTER  DATA  FROM  KEYBOARD  (Y/N)? 

If  the  response  "N"  is  typed,  ASOAR  searches  for  the 
maintenance  downtime  data  in  the  file  CASE6.DAT.  Since  this 
file  does  not  yet  exist,  the  data  must  be  entered  from  the 
keyboard.  The  data  from  the  keyboard  will  be  stored  in  the  file 
CASE6.DAT.  Type  "Y"  and  hit  the  RETURN  key. 
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HOW  MANY  DIFFERENT  END  ITEMS  MtE  IN  THIS  CATEGORY? 

II 

Type  "2”  and  hit  the  RETURN  key. 

CASE  6:  END  ITEM  SCHEDULED  MAINTENANCE 

OR  PERIODIC  STARTUP  CAUSING  SYSTEM  DOWNTIME 


MEAN  CALENDAR 

MEAN 

ITEM 

ITEM 

TIME  BETWEEN 

MAINTENANCE 

NAME 

NUMBER 

MAINTENANCE 

DOWNTIME 

AAAAAAA 

II 

FFFFF.FF 

FFFF.FF 

As  in  CASE  5,  the  Mean  Calendar  Time  Between  Maintenance 
(MCTBM)  tells  how  frequent  this  additional  downtime  occurs  and 
the  Mean  Maintenance  Downtime  (MMDT)  tells  how  long  that  the  end 
item  and  system  are  additionally  down. 

Enter  the  following  data.  Use  the  space  bar  and  backspace 
key  to  move  between  fields  and  hit  the  RETURN  key  when  the  data 
for  an  end  item  is  finished  being  entered. 

iteml  01  500.  .50 

items  03  1000.  2.50 

When  the  data  for  the  last  end  item  is  entered  and  the 
RETURN  key  hit,  ASOAR  asks  whether  any  other  cases  are  to  be 
used  for  this  system. 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED  (Y/N)? 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear : 
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SYSTEM  LEVEL  OUTPUTS 

SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  =  0.93326 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.93333 

MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  29.4 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  -  0.96 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  1.084 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  =  0.9774 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

RATE 

iteml 

1 

150. 

1.25 

1.727 

0.98054 

0.9640 

ltem2 

2 

250. 

1.50 

2.303 

0.98502 

0.9520 

items 

3 

150. 

1.00 

0.345 

0.99111 

0.9928 

item4 

4 

100. 

0.50 

0.461 

0.99049 

0.9904 

items 

5 

150. 

1.00 

1.382 

0.98437 

0.9712 

It*************************************************************** 


NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THL  ASOAR  MODEL 
ASOAR  COMPLETED 
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CASE  7;  MOLTIPLE  SYSTEMS  RESTORED  WITH  LRU  SPARES  AT  ORG 
LEVEI. 


Data  Required  -  whether  *he  systt.  art*  Lion  contains 

multiple  identical  systems;  number  of  systems  serviced  at 
Organization  Level. 

CASE  7  handles  the  situation  where  the  ORG  level  supports 
more  than  just  one  system  and  the  operational  availability 
requirement  is  for  a  system  configuration  of  multiple  identical 
systems.  The  LRU  spares  are  storable  at  the  ORG  level  and  can 
be  used  to  bring  up  any  one  of  these  identical  systems. 

After  CASE  "7"  has  been  entered,  ASOAR  asks  for  the  number 
of  systems  serviced  by  the  ORG  level. 


CASE  7  -  MOLTIPLE  SYSTEMS  RESTORED  WITH 
LRU  SPARES  AT  ORG  LEVEL 

ENTER  1  OR  2 

1)  THE  SYSTEM  CONFIGURATION  CONTAINS  MOLTIPLE  IDENTICAL  SYSTEMS 

2)  ORG  LEVEL  SUPPORTS  MOLTIPLE  INDIVIDUAL  SYSTEMS. 


** 


If  the  operational  availability  requirement  is  for  a 
configuration  of  more  than  one  individual  system,  "1"  should  be 
chosen.  If  the  operational  availability  requirement  is  for  an 
individual  system,  "2"  should  be  chosen.  If  "2"  is  chosen, 
ASOAR  would  run  as  if  no  application  of  Case  7  is  involved 
because  the  LRU  order  fill  rate  for  the  multiple  individual 
system  is  identical  to  the  individual  system.  The  same  order 
fill  rate  with  more  LRU  demands  will  generate  greater  LRU 
stock.  For  this  run,  type  "1"  to  run  Case  7,  and  the  following 
prompt  will  appear. 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVE.*  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

NO.  OF  SYSTEMS 
WITHIN  SYSTEM 
CONFIGURATION 
II 

Type  "02"  and  hit  the  RETURN  key.  ASOAR  now  asks  whether 
any  additional  cases  are  to  be  used  for  this  system. 


ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED ( Y/N ) ? 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N”  and  hit  the  RETURN  key.  The  output  tables  then 
appear : 


SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  =  0.93000 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.92999 

MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  14.7 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  0.96 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  0.115 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  =  0.9976 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

RATE 

iteml 

1 

75. 

1.25 

0.183 

0.98126 

0.9962 

item2 

2 

125. 

1.50  , 

0.243 

0.98624 

0.9949 

item3 

3 

75. 

1.00  1 

0.037 

0.98637 

0.9992 

item4 

4 

50. 

0.50  i 

0.049 

0.98915 

0.9990 

items 

5 

75. 

1.00  1 

0.146 

0.98495 

0.9970 

**************************************************************** 


NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EZCREDINGl 9,999,999.  HOURS 

1 

I 

THANK  YOU  FOR  USING  THE  ASOAR  MODEL 
ASOAR  COMPLETED 
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CASE  8;  SYSTEMS  RESTORED  WITH  LRUS  STOCKED  FORWARD  AT  PS 
LEVEL 


CASES  8,  9,  and  10  describe  systems  without  spares  at  the 
operating  level  or  ORG  level.  These  cases  imply  that  N  systems 
are  serviced  by  a  centralized  area  that  brings  any  of  these 
systems  to  an  up  state  after  going  down.  This  centralized 
support  stores  the  spares  that  restore  the  system  and  is  the 
most  forward  level  of  supply.  One  example  might  be  a  Contact 
Maintenance  Team  where  maintenance  personnel  travel  with  spares 
to  the  system  to  restore  it.  Another  example  could  be  a  Direct 
Exchange  point  where  failed  end  items  or  LRUs  are  brought  and 
exchanged  for  a  working  spare  to  restore  the  system.  A  final 
exeunple  could  be  a  DS  shop  to  where  failed  systems  are  evacuated 
for  restoral.  The  similarities  of  these  exeunples  are  that 
spares  are  not  stored  forward  wirh  the  system  and  some  delay 
time  occurs  before  restoral  of  the  system  can  be  accomplished. 

Data  Required  -  the  number  of  end  items  with  LRUs  stocked 
forward  at  DS  level;  the  item  ntimber  of  the  end  item 
serviced  by  the  DS  level;  the  mean  delay  time  to  restore 
from  a  DS  level  (hours). 

CASE  8  is  used  for  system  restoral  with  LRUs  located  at  the 
DS  level.  The  DS  level  is  a  centralized  support  area  servicing 
various  system  sites.  The  average  down  time  between  the  time 
the  end  item  and  system  have  failed  and  the  time  required  for 
the  LRU  to  be  brought  to  the  equipment  is  the  Mean  Delay  Time  to 
Restore  (MDTR).  MDTR  may  also  represent  the  average  time  to 
evacuate  the  equipment  to  DS  to  start  its  maintainability 
maintenance  plus  the  time  to  return  the  repaired  equipment  back 
to  the  site  if  applicable. 

After  CASE  "8"  has  been  entered,  ASOAR  asks  for  the  MDTR 
from  the  DS  level. 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

CASE  8:  SYSTEM  RESTORED  WITH  LRUS  AT  DIRECT  SUPPORT  LEVEL 

MEAN  DELAY  TIME  TO  RESTORE  FROM  DIRECT  SUPPORT  LEVEL 
FFFF. 

For  this  example,  enter  "3."  hours  for  the  MRDT.  After 
entering  this  value,  ASOAR  will  ask  for  the  number  of  different 
end  items  in  this  category  and  their  item  numbers,  prompting  the 
following . 
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ENTER  THE  QUANTITY  OF  DIFFERENT  END  ITEMS 

AND  THE  ITEM  NUMBER  OF  THESE  END  ITEMS  WHERE  THE  SYSTEM 

IS  RESTORED  WITH  LRU  SPARES  AT  DIRECT  SUPPORT  LEVEL 

HOW  MANY  DIFFERENT  END  ITEMS  ARE  IN  THIS  CATEGORY? 

II 

Enter  "2"  and  hit  return  for  this  exercise.  The  following 
prompt  wiJl  now  appear: 

ITEM  NUMBER 
II 

Type  in  as  the  following: 

1 

3 

ASOAR  now  asks  whether  any  additional  cases  are  to  be  used 
for  this  system. 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED{ Y/N) ? 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear: 
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SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  =  0.93000 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.92998 

MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  29.4 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  2.14 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  0.022 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  =  0.9996 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

RATE 

iteml 

1 

150. 

4.25 

0.034 

0.97223 

0.9993 

item2 

2 

250. 

1.50 

0.046 

0.99385 

0.9990 

item3 

3 

150. 

4.00 

0.007 

0.97398 

0.9999 

item4 

4 

100. 

0.50 

0.009 

0.99493 

0.9998 

items 

5 

150. 

1.00 

0.027 

0.99320 

0.9994 

**********************  ^r***************************************** 


NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASQAR  MODEL 
ASQAR  COMPLETED 
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CASE  9;  SYSTEMS  RESTORED  WITH  END  ITEM  SPARES  AND  LRU  SPARES 
STOCKED  FORWARD  AT  PS  LEVEL 


Data  Required  -  the  number  of  systems  serviced  by  a  DS 
level;  the  mean  delay  time  to  restore  from  a  DS  level 
(hours);  the  number  of  end  items  with  end  item  and  LRU 
spares  stocked  forward  at  DS  level;  the  item  number  of  the 
end  item  serviced  by  the  DS  level;  number  of  floats  for  each 
end  item. 

CASE  9  is  similar  in  some  ways  to  CASE  8.  However,  CASE  9 
has  the  system  being  restored  with  either  end  item  floats  or 
LRUs.  Both  the  end  item  spares  and  the  LRUs  are  stocked  at  the 
DS  level.  Since  uhe  DS  level  has  end  item  spares  stored  at  a 
centralized  support  area  for  more  than  one  system,  ASOAR  must 
know  the  niimber  of  systems  serviced  by  the  DS  level.  MDTR  is 
the  average  time  required  for  the  LRU  or  the  end  item  float  to 
be  brought  to  the  equipment  from  DS  once  the  end  item  and  system 
have  failed.  MDTR  may  also  represent  the  average  time  to 
evacuate  the  equipment  to  DS,  perform  end  item  removal  and 
replacement  at  DS,  and  return  the  repaired  equipment  back  to  the 
site  if  applicable.  ASOAR  must  also  be  supplied  with  the  number 
of  floats  at  DS  associated  with  the  end  item. 

After  CASE  "9"  has  been  entered,  ASOAR  asks  for  the  number 
of  systems  serviced  by  the  DS  level  and  for  the  MDTR  from  the  DS 
level . 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

CASE  9  -  SYSTEM  RESTORED  WITH  END  ITEM  SPARES 
AND  LRUS  AT  DIRECT  SUPPORT  LEVEL 

NO.  OF  SYSTEMS 

SERVICED  BY  MEAN  DELAY  TIME 

DIRECT  SUPPORT  TO  RESTORE  FROM 

LEVEL  DIRECT  SUPPORT 

II  FFFF. 

For  this  example,  the  DS  level  will  service  5  systems  and 
the  MDTR  will  be  3  hours.  Enter  the  following  data  values: 

5  3. 

ASOAR  now  prompts  for  data  on  the  number  of  floats  for  each 
of  the  end  items  in  the  system. 
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ENTER  TnE  QUANTITY  OF  DIFFERENT  END  ITEMS, 

THE  ITEM  NUMBERS  OF  THESE  END  ITEMS,  AND  THE  NUMBER 

OF  END  ITEM  FLOATS  AT  THE  DIRECT  S^PORT 

LEVEL  FOR  EACH  RESPECTIVE  END  ITEM 

HOW  MANY  DIFFERENT  END  ITEMS  ARE  IN  THIS  CATEGORY? 

II 

Three  different  end  items  in  the  sample  systcin  will  Iiavn 
floats.  Type  "3"  and  hit  the  RETURN  key. 

ITEM  NUMBER  NUMBER  OF  FLOATS 

II  II 

Items  1,  3,  and  5  will  have  2  floats  each  at  the  DS  level. 
Enter  the  following  data  using  the  space  bar  and  backspace  key 
to  move  between  fields.  Hit  the  RETURN  key  to  enter  data  for 
the  next  end  item. 

1  '  2 
3  2 

5  2 

When  the  data  for  the  last  end  item  is  entered  and  the 
RETURN  key  hit,  ASOAR  asks  whether  any  other  cases  are  to  be 
used  for  this  system. 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED ( Y/N ) ? 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear: 
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SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL 
ADJUSTED  OPERATIONAL  AVAIL  GOAL 
END  ITEM  OPERATIONAL  AVAIL  PRODUCT 


0.93000 

0.98692 

0.98700 


MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)= 
SYSTEM  ME2^  TIME  TO  RESTORE  (HRS) 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS) 
SYSTEM  ORDER  FILL  RATE  OF  LRUS 


69.7 

0.79 

0.121 

0.9936 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEM:  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

Ao  of  1 

RATE 

item  I 

1 

6463. 

1.25 

3.128 

0.99932 

0.97241 

0.7524 

item2 

2 

250. 

1.50 

0.128 

0.99353 

0.9973 

item3 

3 

16179. 

1.00 

1.597 

0.99984 

0.98309 

0.8585 

item4 

4 

100. 

0.50 

0.026 

0.99477 

0.9995 

items 

5 

7726. 

1.00 

2.943 

0.99949 

0.97495 

0.7744 

*****************************************************  ********** 


NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASOAR  MODEL 
ASOAR  COMPLETED 


49 


CASE  10;  SYSTEM  RESTORED  WITH  END  ITEM  SPARES  AT  PS  LEVEL  AND 
LRUS  STOCKED  FORWARD  AT  GS  LEVEL 


Data  Required  -  the  nximber  of  systeiiib  serviced  by  a  DS 
level;  the  mean  delay  time  to  restore  from  a  DS  level 
(hours);  the  mean  shipping  and  handling  time  between  th  )S 
and  GS  levels  (hours);  the  number  of  end  items  with  end  -em 
spares  stocked  forward  at  DS  level;  the  item  number  of  -*e 
end  items  serviced  by  the  DS  level;  the  number  of  floats  for 
each  end  item. 

CASE  10  is  the  last  of  the  special  cases  in  the  ASOAR 
model.  This  special  case  accomplishes  system  restoral  by  end 
item  floats  located  at  the  DS  level.  The  end  items  are  repaired 
by  LRUs  located  forward  at  the  GS  level.  However,  since  the  DS 
level  has  end  item  spares  stored  at  a  centralized  support  area 
for  more  than  one  system,  ASOAR  must  know  the  number  of  systems 
serviced  by  the  DS  level.  The  GS  level  is  a  more  centralized 
support  area  servicing  various  DS  levels.  The  MDTR  is  the 
average  time  required  for  the  end  item  float  to  be  brought  to 
the  equipment.  MDTR  may  also  represent  the  average  time  to 
evacuate  the  equipment  to  DS,  perform  end  item  removal  and 
replacement  at  DS,  and  return  the  repairnd  equipment  back  to  the 
site  if  applicable.  Finally,  ASOAR  must  be  supplied  with  the 
Mean  Shipping  and  Handling  Time  (MSHT)  between  the  DS  and  GS 
levels  for  the  LRUs,  and  the  number  of  floats  at  DS  associated 
with  the  end  item. 

After  CASE  "10"  has  been  entered,  ASOAR  asks  for  the 
following  data: 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 
HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

CASE  10:  SYSTEM  RESTORED  WITH  END  ITEM  SPARES 

AT  DIRECT  SUPPORT  AND  LRUS  AT  GENERAL  SUPPORT 


NO.  OF  SYSTEMS 
SERVICED  BY 
DIRECT  SUPPORT 
LEVEL 
II 


MEAN  DELAY 
TIME  TO 
RESTORE  FROM 
DIRECT  SUPPORT 
FFFF. 


MEAN  SHIPPING 
AND  HANDLING 
BETWEEN 
DS  AND  GS 
FFFF. 


Type  in  the  following  values.  Use  the  space  bar  and 
backspace  key  to  move  between  fields. 


5 


2. 


2. 
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After  the  value  of  " 2 . "  has  been  entered  for  the  MSHT 
between  DS  and  GS  and  the  RETURN  key  hit,  ASOAR  asks  for  the 
number  of  different  end  items  in  this  category, .their  item 
numbers  and  the  nvunber  of  floats  present  for  each  of  the  end 
items . 

ENTER  THE  QUANTITY  OF  DIFFERENT  END  ITEMS, 

THE  ITEM  NUMBERS  OF  THESE  END  ITEMS,  AND  THE  NUMBER 

OF  END  ITEM  FLOATS  AT  THE  DIRECT  SUPPORT 

LEVEL  FOR  EACH  RESPECTIVE  END  ITEM 

HOW  MANY  DIFFERENT  END  ITEMS  ARE  IN  THIS  CATEGORY? 

II 

Three  different  end  items  in  the  sample  system  will  have 
floats.  Type  ''3"  and  hit  the  RETURN  key. 

ITEM  NUMBER  NUMBER  OF  FLOATS 

II  II 

End  items  1,  3,  and  5  have  2  floats  each  at  the  DS  level. 
Enter  the  following  data  using  the  space  bar  and  backspace  key 
to  move  between  fields .  Hit  the  RETURN  key  to  enter  data  for 
the  next  end  item. 

1 
3 
5 

When  the  data  for  the  last  end  item  is  entered  and  the 
RETURN  key  hit,  ASOAR  asks  whether  any  other  cases  are  to  be 
used  for  this  system. 

ARB  THERE  ANY  ADDITIONAL  CASES  INVOLVED  (Y/N)? 

If  "Y"  is  typed  and  the  RETURN  key  hit,  then  the  special 
cases  menu  reappears.  CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 
explains  the  order  and  combinations  of  permissible  multiple 
cases.  Type  "N"  and  hit  the  RETURN  key.  The  output  tables  then 
appear: 


2 

2 

2 


SYSTEM  LEVEL  ODTPDTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  =  0.96770 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.96763 

MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  64.2 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  1.02 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  1.101 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  =  0.9343 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


MEAN  TIME  TO  OBTAIN  (MTTO)  FOR  EACH  END  ITEMS  48.0 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

Ao  of  1 

RATE 

Iteml 

1 

1484. 

3.25 

8.241 

0.99232 

0.93557 

0.3495 

ltem2 

2 

250. 

1.50 

1.007 

0.99007 

0.9790 

item3 

3 

3295. 

3.00 

3.620 

0.99800 

0.95985 

0.6487 

ltem4 

4 

100. 

0.50 

0.201 

0.99303 

0.9958 

items 

5 

1680. 

3.00 

7.477 

0.99380 

0.94033 

0.4077 

**1t**il1i***ii*********1flt**-k**1t1t*****1t*'IHHt1t*****1i*************1i*1t*1t 

NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASOAR  MODEL 


ASOAR  COMPLETED 


CHAPTER  5.  MULTIPLE  SPECIAL  CASE  RUNS 


More  than  one  special  case  may  be  used  on  to .describe  the 
system  or  its  support  during  the  same  ASOAR  run.  For  some 
combinations  of  special  cases ,  the  order  in  which  the  special 
cases  are  performed  is  important.  Incorrect  answers  will  result 
if  these  special  case  combinations  are  not  used  in  their  proper 
sequence. 

The  following  is  a  review  of  the  special  cases  menu. 

CASE  1:  SERIALLY  CONFIGURED  COMMON  END  ITEMS 
CASE  2:  HOT  STANDBY  REDUNDANT  END  ITEMS 

CASE  3:  COLD  STANDBY  REDUNDANCY  OR  END  ITEM  SPARES  WITH  SYSTEM 

CASE  4:  DEGRADATIONAL  REDUNDANCY  OR  CAPACITY  AVAILABILITY 

SYSTEM  SCHEDULED  MAINTENANCE  OR  PERIODIC  STARTUP 
CAUSING  DOWNTIME 

END  ITEM  SCHEDULED  MAINTENANCE  OR  PERIODIC  STARTUP 
CAUSING  SYSTEM  DOWNTIME 

i 

MULTIPLE  SYSTEMS  RESTORED  WITH  LRU  SPARES  AT  ORG  LEVEL 

i 

SYSTEMS  RESTORED  WITH  LRUS  STOCKED  FORWARD  AT  DS  LEVEL 

' 

SYSTEMS  RESTORED  WITH  END  ITEM  AND  LRUS  STOCKED  FORWARD 
AT  DS  LEVEL 

CASE  10:  SYSTEMS  RESTORED  WITH  END  ITEM  SPARES  AT  DS  AND  LRUS 
STOCKED  FORWARD  AT  GS  LEVEL  i 

With  10  special  cases  available,  the  number  of  case 
combinations  is  extensive.  The  use  of  some  special  cases  should 
automatically  exclude  the  use  of  others.  Other  special  cases, 
such  as  CASE  5,  can  be  reused  more  than  once.  Some  special 
cases  are  independent  of  their  order  of  usage. 

The  user  must  also  be  careful  not  to  have  conflicting  end 
item  configuration  data  when  reusing  special  CASES  1  through  4 . 
For  example,  consider  a  system  having  5  end  items  labeled  A,  B, 

C,  D,  and  E  and  utilizing  special  CASES  2  (hot  redundancy)  and 
3  (cold  redundancy).  If  special  CASE  2  used  end  items  A,  B,  and 
D  and  special  CASE  3  used  end  items  D  and  E,  then  there  is 
clearly  a  contradiction  present  because  end  item  D  should  not  be 
used  in  both  special  cases. 


CASE  5: 

CASE  6: 

CASE  7: 
CASE  8: 
CASE  9: 
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CASES  5  and  6  are  special  cases  that  are  independent  of 
usage  order.  Regardless  of  the  order  with  any  other  special 
cases  the  order  of  CASES  5  ana  6  does  not  affect  th  outcome. 
However,  model  running  time  can  be  reduced  by  using  CASES  5  and 
6  first. 

CASES  8,  9,  and  10  regarding  centralized  support  without 
LRUs  forward  at  ORG  are  mutually  exclusive  cases.  Using  any  cne 
of  these  3  cases  means  that  the  remaining  2  cases  cannot  be  used 
in  the  same  ASOAR  run . 

The  actual  system  configuration  must  be  known  prior  to 
introducing  any  end  item  floats  or  any  unusual  sparing  schemes. 
This  means  that  any  commonalities  or  redundancies  among  the  end 
items  must  be  considered  before  any  other  system  support 
characteristics.  Therefore,  special  CASES  1  through  4  must  be 
used  prior  to  special  CASES  9  through  10  in  an  ASOAR  run.  The 
order  of  the  system  configuration  special  cases  are  irrelevant. 
The  order  of  centralized  support  without  LRUs  at  ORG  are  also 
independent  among  themselves . 

The  rules  for  the  mentioned  special  cases  help  to 
considerably  restrict  the  usage  combinations  existing  for  all  10 
special  cases.  FIGURE  2  is  a  sequence  diagram  showing  the 
recommended  usage  order  for  the  combinations  of  special  cases. 
Cases  are  listed  in  descending  order  of  use  where  cases  at  the 
top  of  the  tree  ar?  to  be  used  first. 


5-6 

(CASE  5  MAY  BE  USED  REPEATEDLY  IF  REQUIRED) 

i 

I 

I 

1  -  2  -  3  -  4 

I 

I 

I 

I 

i 

7 

I 

I 

I 

I 

I 

8-9-10 

FIGURE  2:  RECOMMENDED  SEQUENCE  OF  SPECIAL  CASE  USAGE 
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CHAPTER  6.  INPUT  DATA  REQUIRED  FOR  ASOAR 


This  chapter  lists  the  input  data  requirements  for  the  ASOAR 
model.  Its  purpose  is  to  aid  in  collecting  the  necessary  data 
to  utilize  ASOAR  in  the  analysis  of  a  weapon  system. 


EQUIPMENT  DATA 


END  ITEM  NAME  -  Up  to  8  characters 

END  ITEM  NUMBER  -  A  number  between  01-99,  to  identify  each  end 

item 

END  ITEM  COST  -  Any  unit  is  acceptable  (dollars,  K  dollars, 

M  dollars,  etc.)  as  long  as  it  is  the  same 
unit  or  relative  cost  used  for  all  end 
items  in  the  system 

LOW  FAILURE,  HIGH  COST 

ASSEMBLY  EXPENSE  -  Must  be  the  same  unit  as  end  item  cost 

SYSTEM  Ao  -  A  number  between  .0001  and  .9999.  This  number 
must  be  a  positive  nximber  and  less  than  1. 


RELIABILITY  INPUTS 

MEAN  CALENDAR  TIME  BETWEEN  FAILURE  (MCTBF)  -  in  hours 

or 

MEAN  TIME  BETWEEN  FAILURE  (MTBF) 

and  OPERATING  HOURS  PER  YEAR  -  in  hours 

or 

MTBF,  OPERATING  HOURS  PER  YEAR 

and  NON-OPERATING  MEAN  TIME  TO  FAILURE  -  in  hours 

or 

FAILURE  FACTOR  -  Number  of  end  item  failures  for  100  end  items 

over  a  calendar  year 
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MAINTAINABILITY  INPUTS 


MEAN  TIME  TO  RESORE  (MTR)  -  in  hours 
or 

MEAN  TIME  TO  REPAIR  (MTTR)  -  in  hours 
or 

MTTR  and  ADDITIONAL  ORG  LEVEL  DOWNTIME  PER  FAILURE  -  in  hours 

LOGISTICS  DATA 


Will  the  MEAN  TIME  TO  OBTAIN  (MTTO)  LRU  SPARES  be  the  same  or 
different  for  each  identified  end  item? 


LRU  SUPPLY  SUPPORT  COMBINATION  CODE  (1,7)  ; 

1)  ORG,  DS,  GS,  DEP 

2)  ORG,  DS,  DEP 

3)  ORG,  GS,  DEP 

4)  ORG,  DEP 

5)  DS,  GS,  DEP  (Used  with  special  case  8  or  9) 

6)  DS,  DEP  (Used  with  special  case  8  or  9) 

7)  GS,  DEP  (Used  with  special  case  10) 


Will  the  MEAN  TIME  TO  OBTAIN  (MTTO)  LRU  SPARES  be  an  input  cr  be 
calculated  by  the  model? 


IF  MTTO  IS  INPUTTED  FOR  THE  SYSTEM  OR  EACH  DIFFERENT  END  ITEM 
MEAN  TIME  TO  OBTAIN  (MTTO)  LRU  SPARES  -  in  hours 


IF  MTTO  IS  CALCULATED  FOR  THE  SYSTEM  OR  EACH  DIFFERENT  END  ITEM 


DEFAULT  VALUES  CHANGABLE  BY  INPUT  DATA 
1)  LRU  Stock  Availability  at 


a. 

DS 

=  .95 

b. 

GS 

=  .95 

c. 

Depot 

=  .85 

Order  Ship 

Time 

a. 

Depot 

to  GS  = 

30  days 

b. 

GS  to 

DS 

30  days 

c. 

DS  to 

ORG 

2  days 

3)  Washout  Rate  (Percentage  of  LRUS  Not  Repaired  or  Returened 

to  Stock)  =  .15 

4)  Percentage  Repaired  at 


a. 

Depot 

=  .8500  * 

b. 

GS 

=  0.0  ** 

c. 

DS 

=  0.0  ** 

d. 

ORG 

=  0.0  ** 

Average  Repair  Cycle  Time  at 

a. 

Depot 

=  75  Days 

b. 

GS 

=  30  Days  *** 

c. 

DS 

=»  2  Days  *  *  * 

d. 

ORG 

=*  1  Day  *** 

6)  Mean  Time  to  Obtain  Backorder  at  Depot  =  120  Days 


*  If  the  Washout  Rate  Percentage  is  changed,  the  Depot  repair 
Percentage  Default  will  automatically  change  so  that  the  total 
adds  to  1.00. 

**  If  the  Depot  repair  Percentage  is  changed,  the  GS  Repair 
Percentage  Default  will  automatically  change  so  that  the  Washout 
Rate  and  Repair  Percentages  adds  to  1.00.  Changes  to  Repair 
Percentage  Defaults  may  similarly  continue. 

***  If  the  Repair  Percentags  is  0.0,  the  Average  Repair  Cycle 
Time  is  not  inputted. 
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SPECIAL  CASE  INPUTS  AND  PROMPTS 


CASE 

CASE 

CASE 

CASE 

CASE 

CASE 

CASE 

CASE 

CASE 

Case 


1:  Serially  Configured  Common  End  Items 

2:  Hot  Standby  Redundant  End  Items 

3:  Cold  Standby  Redundancy  or  End  Item  Spares  with  Sys 

4;  Degradational  Redundancy  or  Capacity  Availability 

5 :  System  Scheduled  Maintenance  or  Periodic  Startup 

Causing  Downtime 

6;  End  Item  Scheduled  Maintenance  or  Periodic  Startup 
Causing  System  Downtime  I 

7 ;  Multiple  Systems  Restored  with  Line  Replaceable  Unit 
(LRU)  Spares  Stocked  Forward  at  Organizational  (ORG) 
Level 

8;  System  Restored  with  LRU  Spares  Stocked  Forward  at 
Direct  Support  (DS)  Level 

9:  System  Restored  with  End  Item  Spares  and  LRU  Spares 
Stocked  Forward  at  DS  Level 

10:  System  Restored  with  End  Item  Spares  at  DS  Level  and 
LRU  Spares  Stocked  Forward  at  General  Support  (GS) 
Level 


-m 
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CASE  1 ; 


SERIALLY  CONFIGURED  COMMON  END  ITEMS 


This  case  implies  that  there  is  more  than  one  common  end 
item  in  a  series  configuration  in  the  system.  All  of  the  end 
items  must  be  operational  for  the  system  to  be  in  an  up  state. 


DATA  REQUIRED: 

1)  Number  of  different  end  items  having  common  end  items 

2)  For  each  common  end  item  list: 

a .  Item  Name 

b.  Item  Number 

c.  Quantity  of  end  item  within  system 


CASE  2;  HOT  STANDBY  REDUNDANT  END  ITEMS 


This  case  implies  that  there  are  redundant  end  items  in  the 
system  configuration.  That  is,  a  certain  number  of  end  items 
are  required  for  the  system  to  be  fully  up  and  other  end  items 
can  be  considered  extra.  Hot  standby  means  when  one  end  item 
goes  down,  there  is  usualJ.y  a  similar  end  item  operating  that 
can  be  switched  tc  almost  instantaneously. 


DATA  REQUIRED: 

1)  Number  of  different  end  items  with  hot  standby  redundancy 

2)  For  each  hot  standby  redundant  end  item  list: 

a.  Item  Name 

b .  Item  Nvunber 

c.  Number  of  End  Items  within  system  required  for  the 
system,  to  be  up 

d.  Quantity  of  End  Items  operating  within  system 


CASE  3;  COLD  STANDBY  REDUNDANCY  OR  END  ITEM  SPARES  WITH  SYSTEM 


This  case  implies  that  the  cold  stapHhv  redundant  er  items 

or  extra  end  items  are  not  operating  ^ _ _  -o  i;.. -\:ch  ovei  The 

certain  number  of  end  items  required  for  the  system  to  b  fully 
up  are  operating.  Cold  standby  redundancy  has  the  advar  ge  of 
operating  less  total  end  items  than  hot  standby  redunda”  /. 
Hov/ever,  when  one  of  the  required  operating  end  items  .Is,  the 
system  is  down  until  a  similar  extra  end  item  is  switr  d  to  and 
operating.  Therefore,  downtime  is  associated  to  swit  over  to 

a  cold  standby  redundant  end  item  or  end  item  spare  s  .eked 
forward  with  the  system. 

DATA  REQUIRED: 

1.  For  each  cold  standby  redundant  end  item  list: 

a.  Item  Name 

b.  Item  Number 

c.  Mean  Maintenance  Downtime  to  switch  over 

2.  For  each  cold  standby  redundant  end  item  list: 

a.  Item  Name 

b.  Item  Number 

c.  Number  of  end  items  operating  and  required  to  be  up 

d.  Quantity  of  end  items  with  the  system 


CASE  4;  DEGRADATIONAIi  REDUNDANCY  OR  CAPACITY  AVAILABILITY 


Degradational  redundancy  is  used  to  describe  the  existence 
of  a  state  of  operation  where  the  system  can  be  between  the 
levels  of  being  fully  up  and  fully  down.  This  is  analogous  to 
operating  at  less  than  100%  of  the  required  capacity,  but 
operating  at  some  percent  of  upness  greater  than  0%.  It  applies 
to  both  hot  standby  and  cold  standby  redundancies. 

DATA  REQUIRED: 

1.  Is  the  Degradational  Redundancy  Hot  or  Cold  Standby 
Redundancy? 

2.  For  each  redundant  End  Item  list: 

a .  Item  Name 

b.  Item  Number 

c.  Inputs  2.C.  and  2.d.  of  Case  2  or  Case  3 

3 .  Minimum  number  of  end  items  operational  to  be  considered 
fully  up 

4.  Maximum  number  of  end  items  operational  to  be  considered 
fully  down 

5.  Enter  the  percentage  of  upness  associated  with  each  state 
between  the  one  end  item  less  than  the  minimum  number  of  end 
items  operational  to  be  considered  fully  up  and  one  end  item 
more  than  the  maximxim  number  of  end  items  operational  to  be 
considered  fully  down. 

6.  For  each  cold  standby  redundant  end  item  list: 

a .  Item  Name 

b.  Item  Number 

c.  Mean  Maintenance  Downtime  to  Switch  Over 


CASE  5:  SYSTEM  SCHEDULED  MAINTENANCE  OR  PERIODIC  STARTUP  CAUSING 
DOWNTIME 


This  case  implies  that  there  is  syui.^..i  prevent-dtive 
maintenance,  periodic  relocation  of  the  system  which  trans:  ions 
the  system  to  a  down  state,  or  some  other  foreseen  reason  using 
additional  periodic  downtime.  With  preventative  maintena-  a,  the 
system  is  serviced  at  a  specified  time  interval.  With  ti 
periodic  relocation  of  the  system;  the  system  is  torn  do  , 
transported  and  set  up  after  some  duration  of  time  or  ui  je.  An 
example  of  other  foreseen  reasons  may  include  computer  luartup 
time  when  periodically  switching  the  system  on. 

DATA  REQUIRED: 

1 .  System  Mean  Calendar  Time  Between  Maintenance  -  in  hours 

2.  System  Mean  Maintenance  Downtime  -  in  hours 


4 

Note;  Case  5  can  be  input  more  than  once  if  necessary. 


CASE  6;  END  ITEMS  SCHEDULED  MAINTENANCE  DOWNTIME  OR  PERIODIC 
STARTUP  CAUSING  SYSTEM  DOWNTIME 


This  case  is  analogous  to  Case  5  when  dealing  with  end  item 
preventative  maintenance  that  causes  the  system  to  not  be 
available.  Case  6  can  also  be  used  to  account  for  additional  end 
item  downtime  due  to  some  other  foreseen  reason  such  as  the 
possibility  of  switching  to  hot  standby  redundant  end  items  when 
the  time  to  switch  over  is  significant.  It  should  be  noted  that 
switching  time  associated  with  cold  standby  redundancy  is  already 
incorporated  in  Cases  3  and  4 . 

DATA  REQUIRED  :  | 

1 .  For  each  end  item  causing  periodic  system  downtime  1 

a.  Item  Name 

b.  Item  Number 

c.  Mean  Calendar  Time  Between  Maintenance  -  in  hours! 

d.  Mean  Maintenance  Downtime  -  in  hours  \ 
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CASE  7;  MULTIPLE  SYSTEMS  RESTORED  WITH  LINE  REPLACEABLE  UNIT 
fLRU^  SPARES  STOCKED  FORWARD  AT  ORGANIZATIONAL  fORG^ 
LEVEL 


This  case  implies  that  there  is  a  system  configuration  of 
multiple  identical  systems  being  serviced  at  the  Organizational 
le'-’-el.  If  the  operational  availability  requirement  is  for  an 
individual  system,  the  ORG  level  supports  multiple  individual 
systems  and  no  additional  inputs  are  needed.  If  the  operational 
availability  requirement  covers  more  than  one  identical  system, 
the  system  configuration  contains  multiple  identical  systems . 

Does  the  ORG  level  support  multiple  individual  systems  or 
does  the  system  configuration  contain  multiple  identical 
systems? 

DATA  REQUIRED  IF  THE  SYSTEI-i  CONFIGURATION  CONTAINS  MULTIPLE 
IDENTICAL  SYSTEMS; 

1.  Number  of  Systems  within  the  System  Configuration 


CASE  8;  SYSTEM  RESTORED  WITH  LRUs  STOCKED  FORWARD  AT  DIRECT 
SUPPORT  ( PS )  LEVEL 


This  case  implies  that  multiple  systems  are  serviced  by  a 
centralized  area  that  brings  any  of  these  systems  to  an  up  state 
after  going  down.  The  DS  level  is  considered  the  centralized 
support  which  stores  the  LRU  spares  and  is  the  most  forward  level 
of  supply. 

DATA  REQUIRED; 

1 .  Mean  Delay  Time  to  Restore  from  DS  Level  -  in  hours 

2.  Number  of  different  end  items  with  LRUs  stocked  forward  at  DS 

3.  Item  Numbers  of  the  end  items  in  this  category 
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CASE  9;  SYSTEM  RESTORED  WITH  END  ITEM  SPARES  AND  LRU 
SPARES  SOTCKED  FORWARD  AT  PS  LEVEL 


This  case  implies  that  the  system  ikd  ..  ..^^ojTod  with 

either  end  item  floats  or  LRU  spares  which  are  both  stocked  at 
the  DS  level  and  the  DS  level  is  the  most  forward  level  of 
supply. 

DATA  REQUIRED: 

1.  Nximber  of  systems  serviced  by  the  Direct  Support  (DS)  level 

2.  Mean  Delay  Time  to  Restore  from  the  DS  level  -  in  hours 

3.  Number  of  different  end  items  with  floats  and  LRU  spares 
stocked  forward  at  the  DS  level 

4 .  For  every  end  item  in  this  category  list : 

a .  Item  number 

b.  Quantity  of  end  item  floats  at  the  DS  level 


CASE  10;  SYSTEM  RESTORED  WITH  END  ITEM  SPARES  AT  DS  LEVEL  AND 
LRUS  STOCKED  FORWARD  AT  GENERAL  SUPPORT  rCS^  LEVEL 


This  case  implies  that  end  item  floats  at  the  DS  level 
rather  that  LRUs  will  be  used  to  restore  the  failed  end  items. 
LRUs  that  repair  failed  end  items  are  located  forward  at  the  more 
centralized  GS  level. 

DATA  REQUIRED: 

1.  Number  of  systems  serviced  by  the  DS  level 

2.  Mean  Delay  Time  to  Restore  from  the  DS  level  -  in  hours 

3.  Mean  Shipping  and  Handling  Time  between  DS  and  GS  -  in  hours 

4 .  Number  of  different  end  items  with  floats  stocked  forward  at 
the  DS  level  and  LRUs  stocked  forward  at  the  GS  level 

5.  For  every  end  item  in  this  category  list: 

a .  Item  number 

b.  Quantity  of  end  item  floats  at  the  DS  level 
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MULTIPLE  SPECIAL  CASE  RUNS 

Wore;  The  best  order  for  inputting  multiple  special  cases  are  as 
follows : 


1st  Group: 
2nd  Group : 
3rd  Group: 
Last  Group: 


Cases  5  and  6 
Cases  1,  2,  3,  and  4 
Case  7 

Cases  8,  9,  and  10 
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CHAPTER  7.  USING  A  FILE  EDITOR  TO  MODIFY  EXISTING  DATA  FILES 
AND  TO  CREATE  NEW  DATA  FILES 


If  the  user  is  familiar  with  an  ASCII  file  editor,  existing 
data  files  can  be  easily  manipulated  to  be  used  in  new  ASOAR 
runs.  The  modification  may  involve  changing  just  one  of  the 
values  of  an  end  item  or  it  may  involve  duplicating  an  existing 
data  file.  This  duplicate  file  can  then  be  completely  changed 
to  represent  a  different  system  design.  Any  changes  or 
creations  can  lead  to  a  variety  of  sensitivity  analysis  being 
done . 

The  failure  data  file  is  the  main  file  used  by  ASOAR.  It  is 
supplied  by  the  user  in  response  to  the  question. 

ENTER  INFORMATION  AS  REQUESTED.  WHEN  COLUMN 

HEADINGS  ARE  GIVEN  ENTER  DATA  UNDER  THE  PROPER  HEADING. 

SHOULD  THERE  BE  ANY  INPUT  MISTAKE  WHICH  CANNOT  BE  CORRECTED, 

YOUR  INPUT  FILE  CAN  BE  MODIFIED  AFTER  THIS  PROGRAM  RUN. 


ENTER  FAILURE  DATA  FILE  NAME: 

The  user  may  create  12  different  types  of  failure  data  files 
by  choosing  4  different  options  for  the  reliability  inputs  and  3 
different  options  for  the  maintainability  inputs.  However, 
since  MTR  and  MTTR  have  the  same  format,  the  failure  data  file 
can  have  8  different  formats  according  to  its  combinations  of 
reliability  and  maintainability  inputs.  The  data  file  formats 
of  all  possible  combinations  will  be  explained. 


First  of 

all 

,  the  file 

TEST1.DAT,  which  the  user  just 

created. 

contains  variables 

1  for  the 

end  item 

name,  the  end  item 

number. 

the  ( 

end 

item  cost. 

the  cost 

of  low  failure  rate  high 

cost  assemblies. 

the  end  item  MCTBF, 

r  and  the 

end  item  MTR.  If 

you  type 

out 

its 

contents , 

the  file 

will  show  the  following 

values : 

5  1 

iteml 

1 

5000. 

0. 

150. 

1.25 

item2 

2 

4000. 

0. 

250. 

1.50 

items 

3 

1000. 

0. 

150. 

1.00 

item4 

4 

2000. 

0. 

100. 

1.50 

item^ 

5 

4000. 

0. 

150. 

1.00 
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The  first  value  in  the  first  row  is  the  number  of  different 
end  items  in  the  system.  It  is  the  user  inputted  value  to  the 
question. 

HOW  MANY  END  ITEMS  ARE  SERIALLY  CONFIGL.  J? 

II 

Recall  that  this  value  cannot  exceed  99,  the  maximum  nvimt  r 
of  end  items  allowed  for  a  system  being  modeled  by  ASOAR. 

The  second  value  is  the  combination  code  created 
automatically  according  to  the  reliability  and  maintainability 
options  which  the  user  chooses  when  inputting  the  failure  data. 
This  value  is  used  internally  for  program  execution  only.  In 
this  exercise,  since  the  user  selected  option  1  for  reliability 
data  and  option  1  for  maintainability  data  in  inputting  failure 
data,  the  combination  code  became  1.  As  discussed  in  chapter  2, 
there  are  4  options  for  inputting  reliability  data  and  3  options 
for  inputting  maintainability  data.  This  leads  to  12  different 
ways  to  inpuc  the  reliability  and  maintainability  data. 
Therefore,  this  combination  code  in  an  integer  between  1  and  12. 

The  remaining  5  rows  show  end  item  data  corresponding  to  the 
variables  described  in  the  preceding  paragraph.  Using  a  file 
editor,  the  user  can  change  some  of  the  end  item  data  values  and 
compare  ASOAR  runs  between  the  original  data  set  and  a  modified 
data  set. 

Before  changing  any  numbers,  it  is  imperative  that  the  user 
know  the  exact  field  length  md  position  of  the  variables  in  the 
file.  This  will  prevent  anj  udsreading  of  data  by  ASOAR. 

FIGURE  3  shows  the  field  wid -h  of  the  variables  in  a  failure 
data  file  of  combination  code  1  with  MCTBP  and  MTR  such  as 
TEST1.DAT.  The  failure  data  file  of  combination  code  2  with 
MCTBF  and  MTTR  also  follows  the  format  in  FIGURE  3. 

Combination  code  1  or  2  -  MCTBF  for  reliability  and  MTR  or 
MTTR  for  maintainability  data 

coliimn  1  is  always  blank  1 

I 

I  e.i.  e.i.  e.i.  high  cost  e.i.  e.i. 

}  name  nim  cost  low  fail  mctbf  mtr(mttr) 

!  10  20  30  40  50 

I  I  '  III 

12345678901234567890123456789012345678901234567896 

II  II 

AAAAAAAA  II  PFFFFFF.  FFFFFFF.  FFFFFFF.  FFF.FF 


FIGURE  3.  COMBINATION  CODE  1  OR  2  FAILURE  DATA  FILE 
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The  first  column  in  the  data  file  must  always  be  left  blank, 
and  there  should  also  be  no  blank  rows  anywhere  in  the  file.  As 
was  mentioned  in  the  general  section,  integer  values  must  be 
right  adjusted.  For  real  numbers,  the  decimal  point  acts  as  a 
reference. 

All  characters  must  be  included  when  trying  to  determine  the 
field  width  of  a  variable.  For  exaumple,  the  end  item  name  has  8 
alphanumeric  characters;  the  end  item  number  is  an  integer 
variable  2  characters  wide;  the  end  item  cost,  the  cost  of  a  low 
failure  rate  high  cost  assemblies,  and  the  end  item  MCTBF  are 
real  variables  8  characters  wide,  giving  it  a  maximum  input 
value  of  9999999.  hours.  The  last  variable,  end  item  MTR  is  a 
real  number  which  can  have  maximum  value  of  999.99. 

In  addition  to  the  previously  mentioned  failure  data  file, 
there  are  other  data  files  associated  with  the  other 
combinations  of  the  reliability  and  maintainability  inputs. 
FIGURE  4  shows  the  format  for  all  failure  data  files  for 
combination  codes  3  through  12. 


Combination  code  3  -  MCTBP  for  reliability  and  MTTR  and 
Additional  Down  Time  per  Failure  (ADTF)  for  maintainability  data 

column  1  is  always  blank 1 

I 

I  e.i  e.i.  e.i.  high  cost  e.i.  e.i.  e.i. 

!  name  num  cost  low  fail  mctbf  mttr  adtf 

I  10  20  30  40  50 

II  '  III 

1234567090123456789012345678901234567890123456789012345 
II  II 

AAAAAAAA  II  FFFFFFF.  PFFFFFP.  FPFPFFF.  FFF.FP  FFFF.FF 
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Combination  code  4  or  5  -  MTBP  and  Operating  Hours  per  Year 
(OPHR)  for  reliability  and  MTR  or  MTTR  for  majjitainability  data 


column  1  is  always  blank! 

I 

i  e.i  e.i.  e.i.  high  cost  e.i.  e.i.  e.i. 

I  name  num  cost  low  fail  mtbf  ophr  mtr(mttr) 

!  10  20  30  40  50 

I  I  I  I  I  I 

1234567890123456789012345678901234567890123456789012345 
II  II 

AAAAAAAA  II  FFFFFFF.  FFFFFFF.  FFFFFFF.  FFFF.F  FFF.FF 


Combination  code  6  -  MTBF  and  OPHR  for  reliability  and  MTTR 
and  ADTF  for  maintainability  data 

colTimn  1  is  always  blank! 

I 

I 

I  e.i  e.i.  e.i.  high  cost  e.i.  e.i.  e.i.  e.i. 

I  name  niim  cost  low  fail  mtbf  ophr  mttr  adtf 

I  10  20  30  40  50  60 

II  I  I  I  I  I 

1234567890123456789012345678901234567890123456789012345678961 
II  II 

AAAAAAAA  II  FFFFFFF.  FFFFFFF.  FFFFFFF.  FFFF.F  FFF.FF  FFFF.FF 


Combination  code  7  or  8  -  MTBF,  OPHR,  and  Non-Operating  Mean 
Time  to  Failure  (NMTTF)  for  reliability  and  MTR  or  MTTR  for 
maintainability  data 


e.i  e.i. 
name  num 


column  1  is  always  bleink! 

1 

e.i.  high  c^ost  e.i.  e.i.  e.i.  e.i. 

cost  low  fall  mtbf  ophr  nmttf  mtr(mttr) 

10  20  1  30  40  50  60 

I  i  \  I  i  I  I 

12345678901234567896l234567896l234567896l234567896l234567896l2 
II  II  1 

AAAAAAAA  II  FFFFFFF.  FFFFFFF.  FFFFFFF.  FFFF.F  FFFFFFF.  FFF.FF 
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Combination  code  9  -  MTBF,  OPHR,  and  NMTTF  for  reliability  and  MTTR 
and  ADTF  for  maintainability  data 

column  1  is  always  blank 1 

I 

I  e.i  e.i.  e.i.  high  cost  e.i.  e.i.  e.i.  e.i.  e.i. 

I  neune  num  cost  low  fail  mtbf  ophr  nmttf  mttr  adtf 

I  10  20  30  40  50  60  70 

II  I  I  I  {  {  { 

1234567890123456789012345678901234567890123456789012345678901234567890 
II  II 

AAAAAAAA  II  FFFFFFF.  FFFFFFF.  FFFFFFF.  FFFF.F  FFFFFFF.  FFF.FF  FFFF.FF 


Combination  code  10  or  11  -  Failure  Factor  (FF)  for  reliability  and 
MTR  or  KTTR  for  maintaineibility  data 

column  1  is  always  blank 1 

I 

I 

I  e.i  e.i.  e.i.  high  cost  e.i.  e.i. 

]  name  num  cost  low  fail  ff  mtr(mttr) 

I  10  20  30  40  50 

II  I  III 

12345678901234567890123456789012345678901234567890 
II  II 

AAAAAAAA  II  FFFFFFF.  FFFFFFF.  FFFFFF.F  FFF.FF 

•  •  •  •  •  • 


Combination  code  12  -  FF  for  reliability  and  MTTR  and  ADTF  for 
maintainability  data 

column  1  is  always  blank 1 

I 

I  e.i  e.i.  e.i.  high  cost  e.i.  e.i.  e.i. 

I  name  num  cost  low  fail  ff  mttr  adtf 

I  10  20  30  40  50 

I  I  I  I  I  I 

1234567890123456789012345678901234567890123456789012345 
II  II 

AAAAAAAA  II  FFFFFFF.  FFFFFFF.  FFFFFF.F  FFF.FF  FFFF.FF 


FIGURE  4.  COMBIMATION  CODE  3  TO  12  FAILURE  DATA  FILES 
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FIGURE  5  shows  the  format  for  the  supportability  data  file 
needed  for  MTTO  calculation.  The  same  restrictions  and 
conditions  that  applied  to  the  failure  data  file  with  respect  to 
column  1  being  blank,  no  blank  rows  in  the  file,.  99  being  the 
maximxim  n’ornber  of  end  items  allowed,  integex  ju.l^3S  being  right 
adjusted,  and  the  decimal  point  of  real  number  acting  as  a 
reference  also  applies  to  all  other  special  cases  data  files. 


column  1  is  always  blank! 

I 

\  10  20  30  40  50 

I  I  I  i  I  I 

1234567890123456789012345678901234567890123456789012345 
F.FPFF  F.FFFF  F.FFFF  FFFFFF.F  FFFFFF.F  FFFFFF.F 
F.FFFF  F.FFFF  F.FFFF  F.FFFF  F.FFFF 
FFFFFF.F  FFFFFF.F  FFFFFF.F  FFFFFF.F  FFFFFF.F 


The  variables  from  left  to  right  are: 

line  1:  LRU  Stock  Availabilities  at  DS,  GS,  and  Depot 

Order  and  Ship  Times  from  DS  to  ORG,  from  GS  to  DS,  and 
from  Depot  to  GS  in  hours 

line  2:  Percentage  of  LRUs  not  repaired  or  returned  to  stock 
Percentage  repaired  at  ORG,  DS,  GS,  and  Depot 
line  3:  Average  Repair  Cycle  Times  at  ORG,  DS,  GS,  and  Depot 
Mean  Time  to  Obtain  Backorder  at  Depot  in  hotirs 


FIGURE  5.  MTTO  DATA  FILE 
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FIGURE  6  through  8  show  the  formats  of  files  that  may  be 
created  which  are  associated  to  the  following  special  cases . 

CASE  2:  HOT  REDUNDANCY  DATA  FILE 
CASE  3:  COLD  REDUNDANCY  DATA  FILE 
CASE  4:  HOT  DEGRADATIONAL  REDUNDANCY  DATA  FILE  OR 
COLD  DEGRADATIONAL  REDUNDANCY  DATA  FILE 
CASE  6:  MAINTENANCE  DOWNTIME  DATA  FILE 


column  1  is  always  bl£uikl 
{  e.i.  e.i. 

I  name  num  r  of  n 

I  10  20  30 

II  I  I 

123456789012345678901234567890 

II 

AAAAAAAA  II  II  II 

AAAAAAAA  II  II  II 


FIGURE  6.  HOT  REDUNDANCY  DATA  FILE 


column  1  is  always  blank 1 
I  e . i .  e.i.  maint . 

{  name  num  downtime  r  of  n 

I  10  20  30  40  50 

II  I  I  I  I 

12345678901234567890123456789612345678901234567890 

II 

AAAAAAAA  II  FF.FF  II  II 

AAAAAAAA  II  FF.FF  II  II 


FIGURE  7.  COLD  REDUNDANCY  DATA  FILE 


coliimn  1  is  always  blank  1 

I 

I  e .  i .  e .  i .  time  maint . 

I  name  num  betw.  maint.  -^owntiiae 

I  10  20  30  -.0  50 

II  I  I  j  I 

12345678901234567890123456789012345678901234567890 

II 

AAAAAAAA  II  FFFFF.FF  FFFF.FF 

AAAAAAAA  II  FFFFF.FF  FFFF.FF 


FIGURE  8.  MAINTENANCE  DOWNTIME  DATA  FILE 


CHAPTER  8.  AHALYSIS  OF  ODTPDT  TABLES 


This  section  examines  the  ASOAR  output  tables’  from  CHAPTER 
2.  GETTING  STARTED;  A  SAMPLE  RUN.  The  tables  are  divided  into 
two  sections.  The  first  section  displays  the  system  level 
outputs.  The  second  section  displays  end  item  level  outputs. 
After  each  section  of  output  are  definitions  of  the  terminology 
used  and  explanations  on  how  the  special  cases  affect  certain 
values . 


SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL  =  0.93000 

ADJUSTED  OPERATIONAL  AVAIL  GOAL  =>  0.93000 

END  ITEM  OPERATIONAL  AVAIL  PRODUCT  =  0.93008 

MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)=  29.4 

SYSTEM  MEAN  TIME  TO  RESTORE  (HRS)  =  0.96 

SYSTEM  MEAN  LOGISTIC  DOWNTIME  (HRS)  =  1.188 

SYSTEM  ORDER  FILL  RATE  OF  LRUS  =  0.9753 


SYSTEM  OPERATIONAL  AVAILABILITY  GOAL:  An  inputted  value. 

It  is  the  percentage  of  time  that  the  user  requires  the  system 
to  be  up  (in  an  operating  or  a  committable  state). 

ADJUSTED  OPERATIONAL  AVAILABILITY  GOAL:  The  system  A., 
goal  is  adjusted  whenever  additional  maintenance  down  times  are 
introduced  into  the  system.  ASOAR  then  computes  end  item  level 
output  values  and  other  system  level  output  values  towards  this 
goal  instead  of  the  system  Ao  goal.  If  there  are  no 
additional  maintenance  down  times  or  delay  times  present,  then 
this  value  has  the  same  value  as  the  system  Ac  goal. 

Tliese  additional  maintenance  down  times  which  cause  system 
Ao  adjustments  can  occur  for  a  variety  of  reasons.  Downtime 
is  present  due  to  unscheduled  maintenance  for  cold  standby 
redundknt  end  items  ( CASE  3  and  CASE  4 ,  choice  2 ) .  Downtime  is 
present  for  system  scheduled  maintenance  or  periodic  startups 
(CASE  5)  and  end  item  scheduled  maintenance  or  periodic  startups 
causing  system  dowi.time  (CASE  6).  Also,  there  exists  additional 
delay  t,imes  associated  with  system  restoral  using  end  item 
floats  (CASE  9  and  CASE  10). 


% 


END  ITEM  OPERATIONAL  AVAIIABILITY  PRODUCT:  This  value  is 
the  product  of  the  Ao  of  all  the  end  items  comprising  the 
system.  These  end  item  Ac,  values  are  located  in  the  end  item 
level  output  table  under  the  coltimn  heading  "Ac."- 

ASOAR  generates  the  end  item  Ac  values  by  continually 
updating  an  end  item's  order  fill  rate,  MCTBF  and  MLDT.  This 
updating  is  done  until  ASOAR  gets  Ao  values  for  the  end  items 
whose  product  (the  end  item  Ao  product)  is  within  tolerance 
of  the  targeted  Ao  goal.  This  targeted  value  is  the  system 
Ao  goal  or  its  adjusted  value  when  system  Ao  goal 
adjustments  are  applied. 

MEAN  CALENDAR  TIME  BETWEEN  FAILURES:  It  is  the 
reciprocal  of  the  calendar  time  failure  rate  of  the  system. 
ASOAR  internally  svims  the  failure  rates  of  all  the  serially 
configured  end  items  in  the  system  to  get  the  system  failure 
rate.  An  equivalent  MCTBF  is  computed  for  those  end  items  not 
serially  configured  so  that  the  summation  of  all  the  end  item 
failure  rates  produces  the  correct  system  MCTBF.  Other  failure 
data  combinations  will  show  the  system  Failure  Factor  (FF)  or 
system  Mean  Time  Between  Failure  (MTBF). 

SYSTEM  MEAN  TIME  TO  RESTORE:  An  MTR  represents  the 
average  amount  of  time  the  system  would  be  down  if  spares  were 
always  on  hand  to  restore  the  item  to  an  operable  condition. 

The  system  MTR  depends  on  each  end  item's  relative  contribution 
to  system  failure  and  their  associated  restoral  time.  For 
serially  configured  end  items,  the  weighted  average  from  each 
end  item's  failure  frequency  which  causes  the  system  to  fail 
multiplied  by  their  respective  MTR  determines  the  system  MTR. 
When  the  forward  sparing  level  is  not  with  the  operating 
equipment  and  end  item  floats  are  not  collocated  with  the 
forward  sparing  level  (CASE  8  and  CASE  10),  additional  time  for 
the  LRU  to  restore  the  end  item  is  applied.  Other  failure  data 
combinations  will  show  the  system  Mean  Time  to  Repair  (MTTR) 
which  is  based  on  maintainability  design  data  -  When  using 
MTTR  data,  the  additional  delay  time  from  spec  T  .  /  Cases  8  or  10 
will  be  reflected  in  the  system  Average  Logistics  Down  Time 
(ALDT)  per  failure  instead  of  the  system  MTR. 

SYSTEM  MEAN  LOGISTIC  DOWNTIME:  An  estimate  of  the  amount 
of  downtime  caused  by  spares  not  always  being  on-hand  to 
restore  the  end  item  and  hence  the  system  when  end  item  failure 
causes  the  system  to  go  down.  The  system  MLDT  depends  on  the 
weighted  average  of  each  end  item's  failure  frequency  which 
causes  the  system  to  fail  multiplied  by  their  respective  MLDT. 
Other  failure  data  combinations  will  show  the  syst-^’"  ALDT.  The 
system  ALDT  value  covers  all  downtime  per  system  failure  not 
associated  to  design  MTTR. 
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SYSTEM  ORDER  FILL  RATE  OP  LRUs:  The  percentage  of  tiroe 
that  the  appropriate  LRU  must  be  spared  at  the  most  forward 
level  of  supply  support  to  restore  the  system  when  it  fails. 
Stock  Availability  differs  from  the  LRU  order  fj,ll  rate  when 
all  end  item  failures  do  not  cause  system  failures.  Stock 
availability  is  based  on  demands  for  the  LRU  whether  or  not  the 
system  had  Liiled,  and  order  fill  rate  is  based  on  LRU  demands 
only  when  the  system  has  failed. 


END  ITEM  LEVEL  OUTPUTS 


MEAN  ' 

TIME  TO 

OBTAIN  (MTTO) 

FOR  EACH 

END  ITEM: 

48.0 

ITEM 

ITIM 

EFFECTIVE  EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBLE 

MCTBF 

MTR 

MLDT 

Ao 

RATE 

iteml 

1 

150. 

1.25 

1.893 

0.97947 

0.9606 

itcm2 

2 

250. 

1.50 

2.524 

0.98416 

0.9474 

it€mi3 

3 

150. 

1.00 

0.379 

0.99089 

0.9921 

item4 

4 

100. 

0.50 

0.505 

0.99005 

0.9895 

items 

5 

150. 

1.00 

1.515 

0.98351 

0.9684 

*************************************************************** 


NOTE:  ********  IN  THE  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


MTTO  FOR  EACH  END  ITEM:  This  is  the  average  time  it 
takes  the  most  forward  level  of  supply  support  to  receive  LRUs 
when  needed.  This  value  is  either  user  inputted  or  calculated 
based  on  the  supply  support  and  maintenance  concept  inputs.  If 
any  end  item  has  a  different  MTTO  value,  then  this  output  table 
will  have  separate  column  listing  each  end  item  MTTO  value. 

EFFECTIVE  MCTBF:  For  an  end  item  having  multiple 
quantities,  computations  for  determining  optimal  end  item  Ao 
goals  require  that  the  common  or  redundant  network  of  like  end 
items  (CASES  1  through  4)  be  combined  to  represent  one  end 
item.  The  MCTBF  causing  a  system  failure  from  this  group  of 
similar  end  items  is  called  the  effective  MCTBF.  An  end  item 
that  is  not  common  or  not  redundant  where  no  multiple  systems 
or  end  iter.,  spares  exist  will  have  its  effective  MCTBF  equal  to 
the  user  inputted  MCTBF  for  that  end  item.  Other  failure  data 
combination!?  will  show  EFFECTIVE  FF  or  EFFECTIVE  MTBF. 
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EFFECTIVE  MTR:  This  value  is  usually  the  same  as  the  user 
input.  However,  for  the  special  cases  8  or  10,  extra  delay  time 
will  bo  added  to  this  value.  Other  failure  data  combinations 
will  show  EFFECTIVE  MTTR  instead  of  EFFECTIVE  MTR.  When  using 
MTTR  data,  the  additional  del  ti:..;  zz  zLzl  2'  C  10 

will  be  added  to  the  value  of  EFFECTIVE  ALDT. 

EFFECTIVE  MLDT;  It  is  approximately  equal  to  the 
probability  of  not  filling  an  order  from  operating  level  stock 
times  the  mean  time  to  obtain  LRU  spares .  ASOAR  actually 
computes  the  effective  MLDT  by  using  the  relative  cost  to 
failure  rate  ratio  of  the  end  items  to  the  system  cost  to 
failure  rate  ratio  and  the  system  MLDT  requirement  needed  to 
achieve  the  system  Ao  goal.  The  MLDT  also  accounts  for 
previous  orders  due  in  from  end  item  redundancies  (CASES  2 
through  4)  and  end  item  floats  (CASES  9  and  10).  Other  failure 
data  combinations  will  show  EFFECTIVE  ALDT  values  in  this 
column.  EFFECTIVE  ALDT  covers  all  downtime  per  system  failure 
not  associated  to  the  design  MTTR. 

A*,:  It  is  the  percentage  of  time  that  an  end  item  or 

group  of  similar  end  items  must  be  up  (operating  or  in  a 
committable  state)  in  order  to  achieve  the  system  Ao  goal. 

Ao  OF  1  END  ITEM  (Ao  of  l)s  It  is  the  percentage  of 
time  that  1  end  item  from  a  group  of  similar  end  items  must  be 
up  (operating  or  in  a  committable  state)  in  order  to  achieve  the 
system  Ao  goal.  This  value  is  not  shown  in  this  example,  but 
end  items  associated  with  special  CASES  1  through  4  (redundant 
and  common  end  items)  or  CASES  9  or  10  will  have  a  separate 
column  for  this  value.  This  value  is  also  applied  as  the  end 
item  Ao  goal  input  to  end  item  sparing  and  maintenance 
optimization  models. 

FILL  RATE;  It  is  the  percentage  of  end  item  failures 
requiring  appropriate  LRUs  to  be  spared  at  the  most  forward 
level  of  supply  support  to  restore  the  failed  end  item  when  it 
caused  the  system  to  fail.  Stock  Availability  used  in  MTTO 
computations  often  differs  from  the  LRU  order  fill  rate.  Stock 
availability  is  based  on  demands  for  LRUs  whether  or  not  the 
system  has  failed,  and  order  fill  rate  is  based  on  demands  for 
LRUs  only  when  the  system  has  failed. 

Finally,  the  remark  on  high  reliability  is  noted.  This 
value  of  ***r****-fr  will  appear  if  the  end  item  is  so  reliable 
that  the  Effective  MCTBF  or  MTBF  value  exceeds  9,999,999  hours. 
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CHAPTER  9.  ODTPDT  MESSAGES 


This  chapter  examines  the  output  messages  that  may  appear 
with  an  ASOAR  run.  An  output  message  will  alwavs  accompany  a 
failed  ASOAR  run  but  it  may  be  present  with  a  successful  run 
also. 

A  successful  ASOAR  run  is  indicated  by  the  appearance  of  the 
system  and  end  item  level  output  tables.  A  non-zero  value  for 
any  end  item  LRU  order  fill  rate  means  that  to  meet  the  Ao 
goal,  some  of  the  end  item's  LRUs  are  needed  to  be  stocked 
forward  at  the  most  forward  level  of  supply  support  to  restore  a 
failed  end  item  and  system.  A  non-zero  value  for  any  end  item 
fill  rate  also  produces  a  non-zero  value  for  the  system  order 
fill  rate  of  LRUs. 

When  the  fill  rates  for  all  of  the  end  items  are  equal  to 
zero,  no  sparing  of  LRUs  are  needed  at  the  forward  level  of 
supply  support  to  meet  the  system  Ao  goal.  This  happens  when 
the  input  data  provided  by  the  user  produces  end  item  Ao 
values  without  forward  level  spares,  that  when  multiplied 
together,  exceed  the  Ao  goal  to  be  met  by  the  system.  The 
following  message  then  appears  before  the  output  tables  are 
shown: 

THE  MINIMUM  ACHIEVABLE  END  Ii,m  OPERATIONAL  AVAILABILITY 

PRODUCT  IS  .xxxxx. 

THIS  VALUE  EXCEEDS  THE  (ADJUST  D)  OPERATIONAL  AVAILABILITY 

PRODUCT  OF  .xxxxx. 

This  implies  that  some  design  and  logistics  characteristics 
of  the  system  or  of  the  end  items  causes  the  inputted  or 
adjusted  Ao  goal  to  be  met  without  having  to  spare  at  tne 
operating  level.  It  may  be  that  some  or  all  of  the  end  items 
are  very  reliable  with  high  effective  MCTBF  values,  that  the 
inputted  o-r  adjusted  system  Ao  value  is  '.ow,  and/or  that 
spares  can  be  obtained  from  the  next  hig.ier  support  level 
quickly  yielding  small  MTTO  values.  To  illustrate  one  of  these 
points,  if  the  sample  session  in  CHAPTER  GETTING  STARTED:  A 
SAMPLE  RUN  was  repeated  with  the  same  dati  except  that  the  end 
item  MCTBF 's  were  all  increased  by  a  facto":  of  100,  the 
following  would  result: 
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MINIMUM  ACHIEVABLE  END  ITEM  OPERATIONAL  AVAILABILITY  PRODUCT  =0.98352 
WHICH  EXCEEDS  THE  AD.^TSTED  OPERATIONAL  AVAILABILITY  GOAL  OF  0.93000 


SYSTEM  LEVEL  OUTPUTS 


SYSTEM  OPERATIONAL  AVAIL  GOAL 
ADJUSTED  OPERATIONAL  AVAIL  GOAL 
END  ITEM  OPERATIONAL  AVAIL  PRODUCT 


0.93000 

0.93000 

0.98352 


MEAN  CALENDAR  TIME  BETW  FAILURES  (HRS)= 
SYSTEM  MEAN  TIME  TO  RESTORE  (HRS) 

SYSTEM  MEAN  LOGISTIC  DOWN  TIME  (HRS)  = 
SYSTEM  ORDER  FILL  RATE  OP  LRUS 


2941.2 

0.96 

48.000 

0.0000 


HIT  RETURN  TO  SEE  END  ITEM  OUTPUT  DATA 


END  ITEM  LEVEL  OUTPUT 


ITEM 

ITEM 

EFFECTIVE 

EFFECTIVE 

EFFECTIVE 

FILL 

NAME 

NUMBER 

MCTBF 

MTR 

MLDT 

Ao 

RATE 

iteml 

1 

15000. 

1.25 

48.000 

0.99673 

0.0000 

item2 

2 

25000. 

1.50 

48.000 

0.99802 

0.0000 

itein3 

3 

15000. 

1.00 

48.000 

0.99674 

0.0000 

itein4 

4 

10000. 

0.50 

48.000 

0.99517 

0.0000 

items 

5 

15000. 

1.00 

48.000 

0.99674 

0.0000 

•k  it  it  it  it  it  "k  it  "k  it  It  It  It  it  it  it  *  it  it  irit  it  it  it  it  it  it  it  ft  it  it  it ’k  1i  Hit  a  "it  it  it  it  it  ititik  it it  it  "k -kit  it  ie  it  it  •kit  it  ft*  it  it  it 


NOTE:  ********  IN  RELIABILITY  COLUMN  REPRESENTS 

A  RELIABILITY  EXCEEDING  9,999,999.  HOURS 


THANK  YOU  FOR  USING  THE  ASOAR  MODEL 


ASOAR  COMPLETED 


There  are  instances  when  ASOAR  is  not  able  to  provide  system  and 
end  item  level  output  tables  even  though  the  sytem  Ao  goal  can  be 
achieved.  If  no  output  tables  can  be  provided,  ihe  following  message 
appears : 

(ADJUSTED)  SYSTEM  OPERATIONAL  AVAILABILITY  GOAL  OF 
.xxxxx  IS  ACHIEVABLE. 

THE  MAXIMUM  ACHIEVABLE  SYSTEM  OPERATIONAL  AVAILABILITY 
WITH  100%  LRU  ORDER  FILL  RATES  FOR  ALL  END  ITEMS  IS  .xxxxx. 

ASOAR  PRESENTLY  CANNOT  PRORATE  TO  THE  END  ITEM  LEVEL 
BECAUSE  THE  END  ITEM  OPERATIONAL  AVAILABILITY  PRODUCT 
IS  NOT  REFINING  TO  WITHIN  .0001  OF  THE  ADJUSTED 
OPERATIONAL  AVAILABILITY  GOAL. 

This  situation  may  occur  when  there  is  a  lot  of  redundancy  and 
floats  present  for  all  or  most  of  the  end  items  in  the  system.  CASES 
2,  3,  4,  9,  and  10  are  associated  with  end  item  redundancies  and 
floats.  ASOAR  starts  its  internal  calculations  with  a  "worst"  case 
situation  which  does  not  take  into  account  sparing  to  those 
redundancies  and  floats.  This  produces  minimum  values  for 
reliability  and  Ao  variables  which  may  cause  the  Ao  goal  to  appear 
not  achievable.  If  the  Ao  appears  unachievable,  ASOAR  then 
internally  calculates  a  "best"  case  situation  using  full  sparing  for 
the  end  item  reduncancies  and  floats  which  provides  the  largest 
effective  reliability.  The  present  version  of  ASOAR  sometimes  fails 
to  prorate  the  system  Ao  to  the  optimal  end  item  requirements.  The 
appearance  of  the  above  output  message,  however,  will  indicate  to  the 
user  that  the  inputted  system  Ao  is  achievable,  and  the  maximum  Ao 
achievable  if  all  end  items  have  a  100%  LRU  order  fill  rate.  The 
next  release  of  ASOAR  is  expected  to  prorate  the  system  Ao  to  the  end 
item  requirements  and  produce  the  system  and  end  item  level  output 
tables . 

System  and  end  item  level  output  tables  are  also  not  provided 
when  the  system  Ao  goal  is  too  large  and  cannot  be  achieved  even  with 
a  100%  LRU  order  fill  rate.  ASOAR  will  produce  the  following  message 
before  terminating  the  progreun: 

(ADJUSTED)  SYSTEM  OPERATIONAL  AVAILABILITY  GOAL  OF 
.xxxxx  IS  NOT  ACHIEVABLE. 

THE  MAXIMUM  ACHIVABLE  SYSTEM  OPERATIONAL  AVAILABILITY  IS 
.xxxxx. 

This  message  means  that  when  the  system  is  down  due  to  an  end 
item  failure,  the  system  maintainability  cannot  restore  the  system  in 
enough  time  to  meet  its  A*,  goal.  This  type  of  ASOAR  run  can  occur 
for  a  number  of  reasons.  Sometimes  the  user  can  perform  sensitivity 
analysis  on  some  of  the  input  data  to  achieve  an  obtainable  system  Ao 
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goal.  The  system  Ao  goal  may  be  made  obtainable  by  eiv.  ■  :  lowering 
the  system  Ac,  requirement  or  by  improving  the  system  de.-.  gn  which 
increases  its  effective  MCTBF  or  decreases  its  effective  r, R.  If  a 
sensitivity  analysis  does  not  correct  the  problem,  it  may  identify  an 
area  that  needs  some  reconsideration  to  pr^  *“  ''M''''esst.rl  run. 

You  can  contact  the  US  Army  Communications-Eiectronics  Command 
Systems  Analysis  Division  at  DSN  992-8752  or  4684  or  commercial 
(908)532-8752  or  4684. 

There  are  several  diagnostic  messages  caused  by  dividing  by  0  or 
unrealistic  values  such  as  0  operating  hours,  resulting  in 
unsuccessful  ASOAR  run.  The  following  are  the  scimples  of  these 
output  messages: 

THE  NET  COST  OF  EACH  END  ITEM  MUST  BE  A  POSITIVE  NUMBER. 

YOUR  ITEM  NUMBER  XX  HAS  A  NEGATIVE  VALUE  OF  XXXXXXX. 

PLEASE  TRY  AGAIN. 

RELIABILITY  INPUT  OF  MCTBF  OR  MTBF  OF  EACH  END  ITME  SHOULD 
EXCEED  0. 

TRY  AGAIN. 

BOTH  RELIABILITY  INPUTS  OF  MTBF  AND  NON-OPERATING 
MEAN  TIME  TO  FAILURE  SHOULD  EXCEED  0,  OR  OPERATING 
HOURS  PER  YEAR  SHOULD  NOT  EXCEED  8760  HOURS. 

PLEASE  TRY  AGAIN. 

RELIABILITY  INPUT  OF  FAILURE  FACTOR  OF  EACH  END  ITEM 
SHOULD  EXCEED  0. 

PLEASE  TRY  AGAIN. 

MTR  OR  MTTR  INPUT  OF  EACH  END  ITEM  SHOULD  BE  A  POSITIVE 
NUMBER  OR  0. 

TRY  AGAIN. 

BOTH  MTR  AND  ADDITIONAL  ORG  DOWN  TIME  PER  FAILURE 
INPUTS  SHOULD  BE  GREATER  THAN  OR  EQUAL  TO  0. 

PLEASE  TRY  AGAIN. 

A  failure  will  occur  if  the  product  of  the  end  item  Ao  values 
does  not  reach  tJ.e  desired  system  Ao  goal  because  ASOAR  was  forced 
to  suspend  computations.  This  suspension  will  occur  when  the  MLDT 
for  all  of  the  enc  items  have  reached  their  maximum  realistic  value, 
thereby  preventinc  any  further  adjustments.  The  following  failure 
message  then  appeers: 

THE  END  ITEIi  (  PERATIONAL  AVAILABILITY  PRODUCT  IS  .xxxxx. 

THE  (ADJUSTED)  OPERATIONAL  AVAILABILITY  GOAL  OP  .xxxxx 
IS  NOT  ACHIEVABLE  BECAUSE  ALL  END  ITEMS  ARE  FROZEN 
AT  THEIR  MAXIMUM  LOGISTICS  DOWNTIMES. 
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Every  end  item  has  an  upper  limit,  or  maximum,  on  its  IttDT  value. 
This  upper  limit  is  equal  to  the  end  item  MTTO  value  plus  its  MTR 
value,  with  any  redundancy  factored  in.  When  that  limit  is  reached, 
ASOAR  "freezes"  the  MLDT  at  that  value  and  this  prevents  any  further 
adjustments  to  that  end  item.  As  long  as  ASOAR  can  perform 
adjustments  and  computations  on  at  least  1  end  item,  there  is  a  chance 
to  meet  the  system  Ao  goal.  But  if  the  MLDTs  of  all  the  end  items 
are  frozen,  no  more  iterations  or  adjustments  can  be  performed  and 
ASOAR  terminates  the  prograon.  A  higher  Ao  goal  may  be  inputted  and 
the  program  run  again,  but  the  diagnostic  may  be  saying  that  the 
system  Ao  goal  is  more  than  achievable  without  forward  level  LRU 
sparing  due  to  the  high  level  of  redundancy. 

Finally,  a  failure  to  obtain  a  system  and  end  item  level  output 
table  can  occur  during  inputting.  When  failing  to  enter  an  input, 
entering  a  mistaken  input  or  attempting  to  enter  data  from  a  file  that 
does  not  exit,  the  inputting  may  be  terminated  before  the  ASO^ 
program  computes  with  the  data.  If  this  happens,  the  input  file  can 
be  modified  after  progreuti  termination  before  making  another  ASOAR  run 
using  the  input  file  or  the  user  can  start  another  ASOAR  run  and  enter 
new  inputs  from  the  keyboard. 
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CHAPTER  10.  DIAGNOSTIC  PRINTOUT  INFORMATION 


The  diagnostic  printout  feature  of  ASOAR  allows  the  user  to  track 
the  internal  calculations  and  iterations  that  produce  the  values  in 
the  output  tables .  This  feature  can  be  useful  in  determining  why  a 
particular  ASOAR  run  failed,  or  in  simply  trying  to  understand  how 
some  system  and  end  item  values  were  obtained.  However,  regardless 
of  whether  a  run  is  successful  or  unsuccessful,  a  diagnostic  printout 
can  add  considerable  time  to  an  ASOAR  run.  For  a  system  containing 
many  different  kinds  of  end  items  or  for  a  system  that  utilizes  some 
special  cases,  choosing  the  diagnostic  printout  feature  can  make  an 
ASOAR  run  last  several  minutes  or  possibly  hours. 

A  diagnostic  printout  is  obtained  by  responding  to  the  following 
first  prompt  in  the  ASOAR  program  with  a  "1." 

PRESS  ENTER  KEY  FOR  NO  DIAGNOSTIC  PRINTOUT  OR  ENTER  1  FOR 

DIAGNOSTIC  PRINTOUT. 

NOTE:  RECOMMEND  PRESSING  THE  RETURN  KEY  UNLESS  INTERMEDIATE 

COMPUTATION  VALUES  ARE  NECESSARY. 

ENTER  THE  KEY  NOW: 

Essentially,  the  diagnostic  procedure  shows  the  user  the  values 
of  key  variables  as  they  are  being  changed  and  updated.  These 
variables  ultimately  relate  to  a  final  set  of  variables  that  appear 
in  the  system  and  end  item  level  output  tables.  Except  for  some 
immediate  calculations  done  when  a  redundancy  special  case  is  chosen, 
no  diagnostic  output  appears  to  the  user  until  the  following  question 
is  answered  with  a  "N." 

ARE  THERE  ANY  ADDITIONAL  CASES  INVOLVED ( Y/N ) ? 

The  response  of  "N"  indicates  that  there  is  no  more  input  data  to 
be  supplied  and  that  ASOAR  can  begin  its  computations . 

The  following  pages  show  a  partial  diagnostic  printout  obtained 
by  running  the  diagnostic  feature  on  the  cold  redundancy  example  in 
CHAPTER  4.  The  diagnostic  feature  activation  is  only  encouraged  when 
the  entire  output  of  internal  computation  is  desired  to  be  seen. 


MLDTT=  2.424 

I«  1  MLDT(I)=  10308.1  r-LDTT  =  2.424  MCTEF< 1)  =  774369. 

COST!  I)  »  5000.00  MCTEFS  »  56.  COSTSY  »16000.07'0 

1=  2  MLDT(n=>  31.0  -LDTT  =  ..-,2  .  ..  . 

COSTd)  =  4000.00  MCTEFS  =  56.  COSTSY  =16000.000 

I-  3  MLDT(I)=  3.0  MLDTT  =  2.424  MCTEF<n  =  1114. 

COSTd)  »  1000.00  MCTEFS  =>  56.  COSTSY  -16000.000 

I-  4  MLDTd)=  0.3  MLDTT  »  2.424  MCTEFd)  =  100. 

COSTd)  »  2000.00  MCTEFS  -  56.  COSTSY  -16000.000 

I"  3  MLDTd)-  1.6  MLDTT  -  2.424  MCTEF(I)  -130. 

COSTd)  =  4000.00  MCTEFS  -  56.  COSTSY  -16000.000 

I-  IMLDTd)-  6.  93833P0INTd.2)-  2.  00POINT  d  .  3 )  =  7.00 

POINTd.4)-  a.00000POINTd.3)-  4a.00COSTd>-  5000.00MC,TBFd  )=  774369. 

I-  2MLDTd)-  23.23000POINTd,2)-  1 . 00POINT  d  .  3 )  -  2.00 

POINTd.4)-  a. 00000POINTd. 3)-  48.00COSTd)=  4000.  00MCTEF  d  )  =  2834. 

I-  3MLDTd)-  7.62043POINTd,2)-  1 . 00POINT  d  .  3 )  -  2.00 

P0INTd,4)-  0.66200POINTd.3)=  4a.00COSTd)-  1000. 00MCTEFd  )=  2811. 

I-  4MLDTd)»  0.34280POINTd.2)-  0.  00POINT  d  .  3  ) »  0.00 

POINTd.4)-  0.00000POINT<  I. 5)=  0.00COSTd)»  2000.  00MCTEF  (I  )  =  100. 

I-  3MLDTd)=  1.62839P0IN[rd,2)-  0.  00POINT  d  .  3 )  -  0.00 

POINTd.4)-  0.00000POINTd. 3)-  a.00COSTd)-  4000.  aOMCTEF  d  )  =  153. 

MCTEFS-  36. COSTSY-  1 6000. 00MLDTT-  2.42371 

4100 

Press  Enter  to  Continue. 

I  -  I  MCTBFII)  -  774369.  MTR(I)  -  1.23  MLDTd)  -  6.96 

I  -  1  AOd)  -  0.99999 

I  -  2  MCTEFd)  -  2834.  MTRd)  -  1.30  MLDTd)  =  23.25 

I  •  2  AO<I)  -  0.99140 

I  -  3  MCTEFd)  -:  2811.  MTRd)  -  1.00  MLDTd)  -  7.63 

1  -  3  AO<I)  -  0.99694 

I  -  4  MCTEFin  -  100.  MTRd)  -  0.50  MLDTd)  -  0  54 

I  -  4  A0< I)  -  0.98968 

I  -  3  MCTEFd)  -  130.  MTRd)  -  1.00  MLDTd)  -  l.t3 

I  -  3  AOd)  -  0.98278 

I-  1  AOd)-  0.99999  TEMP  AOTAR  -  0.94632 

I-  2  AOd)-  0.99140  TEMP  AOTAR  -  0.95473 

MLDTT-  1.984 

I-  3  MLDTd)-  3.3  MLDTT  -  1.984  MCTEFd)  »  1114. 

COSTd)  -  1000.00  MCTEFS  -  37.  COSTSY  -  7000.000 

I-  4--MLDTri)-  1.0-MtDTT  »■  - 1. 994  MCTEr  (I )  =  100. 

COSTd)  -  2000.00  MCTEFS  -  37.  COSTSY  -  7000.000 

I-  3  MLDTd)-  3.0  MLDTT  -  1.984  MCTEFd)  »  130. 

COSTd)  -  4000.00  MCTEFS  »  37.  COSTSY  -  7000.000 

I-  IMUDTCI)-  ,  .93833P0INTd.2)-  2. 00POINTd .  3)  -  7.00 

POINTd.4)-  0.00000!  OINTd. 3)-  48.00COSTd)-  5000.  00MCTEF  (I  )  -  774369. 

I-  2MLDTd)-  23.23000POINTd.2)-  1 . 00POINT  (1 . 3 )  -  2.00 

POiNTd.4)-  0.00000POINTd.3)-  48.00COSTd)-  4000. 00MCTEFd  )  -  2834. 

I-  3MLDTd)-  10.63213POINTd.2)-  1 . 00POINTd  .  3 )  -  2.00 

P0INTd,4)-  0.33700POINTd.3)-  48. 00COST(  I )  -  1000.  00MCTEFd  )  =  2133. 

I-  4MLDTd)-  0.99387POINTd,2)-  0. 00POINTd .  3)  -  0.00 

POINTd.4)-  0.00O00POINTd.3)-  0.00COST(I)-  2000. 00MCTEF  (I )  -  100. 

I-  3MLDTd)-  2.9B760POINTd.2)-  0.  00POINT  d  .  3 ) »  0.00 

P0INTd,4)-  0.00000POINTd.3 )-  0.00COSTd)-  4000. 00MCTEFd  )  -  130. 

MCTEFS-  37. COSTSY-  7000. 00MLDTT-  1.98441 

4100 

Press  Enter  to  Continue. 
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I  a  1  MCTBFd)  =  774369. 

I  a  1  A0<  1)  =>  0.9999<? 

I  a  2  MCTBFd)  a  2BSA. 

I  a  c  A0< I )  =  0.99140 

I  a  3  MCTBFd)  =  1133. 

I  a  3  AOd)  =  0.99438 

I  a  4  MCTBFd)  100. 


1  a  4  AO«I)  =  0,98326 

I  a  5  MCTBFd)  a  150. 


I  a  5 
MCTBFS- 


AOd)  a  rj.  97410 
37.MTRSYSa  0.72 


N  a  5  PROD*  0.94633  AOTAR; 
ALPHA 


MTRd)  a 
MTRd)  a 
MTRd)  = 
MTRd)  = 
MTRd)  a 

■  0.94651 


1.25  Ml.DTd)  a 
1.50  MLDT(  I  )  a 
1 . 00  MLDT  d  )  a 
0.30  MLDTC  I  )  a 
1.00  MLDTd  )  a 


13.25 

10.63 

1.00 

1.99 


pfess  Enter  to  Continue. 

5;?;  -  a,-*.... ««"  ■ 

ADJMLDT 


Pre*s  Enter  to  Continue. 


I- 
la 
la 
la 

!■ 
la 

1- 
I- 
1- 
1- 
1- 
t- 
1- 

L-  2 

NWKBELa 

MDTXa 

L*  1 

NWKREL- 

MDTXa 

L-  V 

NUKREL- 

MDTX- 


1TMNUM< I )a 
1TMNUM< I )a 
ITMNUMl I )a 
tTMNUMd)a 
ITMNUMl I )a 
ITMNUMl 1 )a 
1TMNUM< I )a 
ITMNUMd)a 
ITMNUMl I )- 
ITMNUm  I  )■ 
MLDTd)-  L 
MLDT  d  )  a 
MLDTID- 
NN-  7  MM- 
0.99994  La 
49.230  LNa 
NN-  2  MM- 
0.90280  L- 
49.300  LN- 
NN-  2  MM- 
0.98927  La 
23. 124  LN- 


MLDTd  )a 

1  MLDTd  )a 

2  MLDTd)- 
2  MLDT( I )» 

MLDT  d  )  a 
MLDTd)- 
MLDT< I )- 
MLDTd)- 
MLDTd  >- 
_  MLDTd  )- 
36223  ALPHA- 
•198932  ALPHA- 
.96793  ALPHA- 
6  COEF 


1 


3 

3 

4 
4 
3 
3 


6.93933  AOd)  a 
6.95833  AOd)a 
23.23000  AOd)a 
23.23000  AOd) a 
10.63213  AO< I )a 
10.37280  AO( I )a 
0.99587  AO< I )a 
0.99031  AOd)- 
2. 997 60  AOd) a 
2.97092  AOd)* 
0.99900 
0.99900 
0.99900 
0.000  NFUP 


0.99999 
a.99‘599 
0.99140 
0.99140 
0,99 458 
0.99461 
0.98326 
0.98332 
0.97410 
0.97421 


0  NFDNa  0  IDUMa 


2  nN—  7  LN—  -0,00006 

0.000  NTMCBF-  774369. 

2  COEF-  0.000  NFUP- 

1  nN-  2  LN-  -0,01733 

-0.017  NTMCBF-  2834. 

2  COEF-  0.000  NFUP- 

I  nN-  2  LN-  -0.01079 

-0.011  NTMCBF-  2144. 


0  NFDN-  0  IDUM" 


0  NFDN-  0  IDUM» 


4100 


Press -Enter  to  Continue, 


I  a 

I  - 
1  - 

1 : 

I  - 
I  - 
I  - 
1  - 

I  a 

MCTBFS' 

N  - 


1  MCTBFd)  -  774369.  MTRd)  - 

1  AOd)  a  0.99999 

2  MCTBFd) 


2834.  MTRd)  « 


■3"MCtBFd)  i'  ‘2144.  MTR<I)  • 

3  AOd)  a  MTOfTJ  - 

4  M2TBF<I)  a  10®*  MTRd) 

4  AOd)  a  0.98333 

3  MCTBFd)  a  150.  MTR<I)  - 

5  AOd)  a  0.97423 

•  37.MTRSYS-  0.72 
3  PROD-  0.94636  AOTAR-  0.94631 


1 . 23  MLDT  d )  a 
1.30  MLDTd  )  a 
1 . 00  MLDT  d )  a 
0.30  MLDTd  )  a 
1,00  MLDTd  )  a 


L-  2  NN-  7  MM- 

NWKREL-  0.99994  L- 
MDTXa  49.230  LN- 
La  I  NN-  2  MM- 

NWKREL-  &.9J280  L- 


6  COEF-  0.000  NFUP- 
2  NN-  7  LN-  -0.00006 

0.000  NTMCBF-  774369. 

2  COEF-  0.000  NFUP- 
j  NN-  2  LN-  -0.01733 


-nryM  49.300  LN-  -0.017  NTMCBF-  2834. 

L-  I  NN-  2  MM-  2  COEF-  0.000  NFUP- 
NUKREL-  0,98927  L-  1  NN-  2  LN-  -0.01079 

|.^QYX-  23.124  IN-  -0.011  NTMCBF-  ».144. 


0  NFON« 
0  NFDN« 
0  NFDN* 


6.96 

23.23 

10.36 

0.99 

2.97 

0  IDUM- 

0  IDUM- 

a  IDUM* 


0.99442 
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The  following  list  defines  the  variables  that  are  used 
during  a  diagnostic  printout.  Some  of  the  variables  are  used 
only  if  certain  special  cases  had  been  chosen.  Those  variables 
are  distinguished  by  a  number,  or  nximbers,  next  to  their  name 
indicating  the  associated  special  case(s).  Note  also  that  a 
variable  may  take  on  more  than  one  meaning  depending  on  the 
special  case  used.  Finally,  some  variables  have  an  asterisk 
next  to  their  name.  These  represent  variables  that  appear 
directly  in  the  output  tables  once  their  final  values  have  been 
calculated. 


VARIABLE  NAME  MEANING 


ADJIN  Initial  adjustment  factor  used  on 

MLDT  prior  to  alpha/beta 
adjustment.  It  is  a  function  of 
AOAM  and  AOTM. 


ALPHA  Factor  used  to  reduce  MLDT, 


AO(I)*  Ao  value  for  each  end  item. 


AOAM  System  Ao  downtime  computed  with 

adjusted  MLDT. 


AOSYS*  System  Ao  (an  entered  number). 


Target  Ao.  It  is  the  system  Ao 
value  with  additional  delay  times 
factored  in.  If  no  additional 
delay  times  are  present,  then  AOTAR 
=  AOSYS. 


AOTM  System  Ao  downtime  computed  with 

MLDT  (the  target  MLDT). 


BETA  Factor  used  to  increase  MLDT. 


AOTAR* 

(3,  4(2),  5,  6,  9,  10) 
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VARIABLE  NAME 


MEANING 


COST(I) 

COSTSY* 

COEF  (4) 

ENDRT 
(9,  10) 

FILLIX  (2,  3,  4) 

FROZEN  MLDT(I) 

ITEM  NO 
ITMNDM(I)* 

L  (2,  3,  4) 

L  (9,  10) 


Cost  of  each  end  item  minus  the  cost  for 
a  low  failure,  high  cost  assembly. 


Cost  of  system  counting  cost  of  the 
redundant  or  common  end  items  only  once. 


Degradation  co-efficient  for  the  end 
items  that  are  degradations!  in  an  R  of 
NN  redundant  network.  It  is  equal  to 
one  if  degradations!  redundancy  does  not 
apply  to  that  end  item. 


End  item  return  time  from  DS. 


Order  fill  rate  at  the  most  forward 
level  of  supply  support  for  the  end 
item. 


The  maximum  realistic  MLDT  value  for  an 
end  item. 

End  item  number. 

End  item  nximber. 


Represents  R  in  an  R  of  NN  redundant 
network . 


NSYS  serviced  by  a  DS  level  for  those 
end  items  having  floats. 


LN  (2,  3,  4,  9, 


10) 


Natural  log  of  the  network  reliability 
calculation  result. 


VARIABLE  NAME 


MEANING 


MCTBF(I)* 

MCTBFS- 

MDTRDS 

MDTX 

(2,  3,  4,  g 
MI’SL  (10) 
MLDT(T)* 

MLDTT 

MM 

MTR(I) 

MTTOIX 
(2,  3,  4,  9 


MCTBF  for  each  end  item. .  For  those  end 

items  having  mulL_^._  _ ‘.ies  or 

occurring  more  than  once  in  a  system, 
this  value  represents  the  effective 
MCTBF . 


System  MCTBF. 

MDTR  the  system  with  LRU  spares  at  DS 
level . 


MDT  per  failure  for  an  end  item. 

,  10) 


Number  of  DS  levels  serviced  by  a  GS. 


MLDT  for  each  end  item.  Appears  in  the 
end  item  level  output  tables  as  the 
effective  MLDT. 


MLDT  target  for  the  system. 


A  value  equal  to  NN-R.  It  represents 
the  actual  nximber  of  redundant  end 
items . 

MTR  for  each  end  item.  A  user  Isupplied 
value.  1 


MTTO  a  spare  when  spares  are  not 
t  10)  available  at  the  most  forward  level  of 

supply  support.  Used  in  redundancy 
calculations  and  for  end  items  with 
floats.  It  is  used  instead  of  biit  is 
equal  to  the  inputted  or  computed  MTTO 
value  for  that  end  item. 


VARIABLE  NAME 

N 

NAME'* 

NFDN  (4) 

NFDP  (4) 

NN  (2,  3,  4) 

hN  (9,  10) 

NSYS  (7,  8,  S, 

NTMCBF 


MEANING 


Number  of  different  end  items  in  the 
system. 


End  item  name. 


The  maximum  number  of  end  items 
operational  to  be  considered  fully 
dovm.  An  inputted  value  used  in 
degradational  redundancy  calculations . 


The  minimum  number  of  end  items 
operational  to  be  considered  fully  up. 
An  inputted  value  used  in  degradational 
redundancy  calculations . 


Total  number  of  end  items  in  a  redundant 
network . 


For  an  end  item  having  floats,  this 
value  is  equal  to  the  number  of  those 
floats  plus  the  number  of  systems 
serviced  by  a  DS  level  (NSYS). 


10)  Number  of  systems  serviced  by  a  DS 

level . 


Net'^’ork  MCTBF.  It  is  used  in  redundancy 
calculations  as  the  MCTBF  value  for  all 
NN  end  items  in  an  R  of  NN  redundancy, 
and  it  is  also  used  as  the  MCTBF  value 
for  end  items  having  floats. 
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VARIABLE  NAME 


NWKREL 

(2,  3,  4,  9,  10) 


POINT  (2,  3,  4) 


POINT{I,l)  = 
POINT(I,2)  = 
POINT(I,3)  = 
P01NT(I,4)  = 
POINT(I,5)  = 


POINT  (9,  10) 


POINT(I,l)  = 
POINT(I,2)  = 
POINT(I,3)  = 
?OINT(I,4)  = 
POINT(I,5)  = 


PROD 


STDSGS  (10) 


TEMP  AOTAR 


MEANING 


Network  reliability.  It, is  used  in 
redunda  zy  calculations  tha 
reliabixity  value  for  all  NN  end  items 
in  an  R  of  NN  redundancy.  It  is  also 
used  as  the  reliability  value  for  end 
items  having  floats.  The  natural  log  oz 
this  value  divided  into  the  end  item 
Mean  Downtime  (MDT)  yields  the  network 
MCTBF . 


Two  dimensional  array  variable  used  in 
redundancy  calculations  to  hold  relevant 
variables  temporarily. 

MCTBF{I) 

L 

NN 

FILLIX 

MTTOIX 


Two  dimensional  array  variable  used  with 
end  items  having  floats  to  hold  relevant 
variables  temporarily. 

MCTBF(I) 

NSYS 

NSYS+(#  of  floats) 

FILLIX 

MTTOIX 


The  product  of  the  Ao  values  of  all 
the  different  end  items. 


MSHT  from  DS  to  GS. 


Temporary  system  Ac  target  (AOTAR) . 

An  end  item  with  a  frozen  MLDT  will  have 
its  Ao  requirement  factored  out  of  the 
AOTAR  value.  This  new,  temporary  AOTAR 
value  is  used  as  a  goal  for  the  other 
end  items. 


mmM 
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CHAPTER  11.  GLOSSARY  OF  TERMS  AND  DEFINITIONS 


AVERAGE  LOGISTICS  DOWNTIME  (ALDT) ;  The  average  amount  of 
downtime  per  failure  due  to  logistics  support.  It  is 
essentially  the  total  downtime  per  failure  less  the  end  item's 
or  system's  designed  maintainability. 


AVERAGE  REPAIR  CYCLE  TIME  (RCT):  Time  from  when  an  LRU  fails 
in  the  end  item  and  is  shipped,  screened/repaired,  and  put  into 
stock  under  conditions  when  stockage  has  been  depleted  at  the 
support  level. 


EFFECTIVE  FAILURE  FACTOR:  The  average  number  of  end  item 
failures  causing  a  system  failure  for  100  end  items  over  a 
calendar  year. 


EFFECTIVE  MEAN  CALENDAR  TIME  BETWEEN  FAILURE:  It  is  the  MCTBF 
of  an  end  item  or  group  of  similar  end  items  causing  a  system 
failure.  An  equivalent  end  item  group  factors  in  the  impact  of 
end  item  redundancy  or  commonality  in  the  end  item  network. 


EFFECTIVE  MEAN  LOGISTICS  DOWNTIME:  It  is  the  MLDT  of  an  end 
item  causing  system  downtime  including  any  end  item  redundancy 
factored  in  to  account  for  previous  orders  due  in  prior  to  a 
system  failure. 


EFFECTIVE  MEAN  TIME  BETWEEN  FAILURE:  It  is  the  MTBF  of  an  end 
item  causing  a  system  failure  including  any  end  item  redundancy 
factored  in  to  represent  the  impact  of  the  end  item  network. 


FAILURE  FACTOR  (FF) :  The  average  number  of  end  item  failures 
for  100  end  Items  over  a  calendar  year.  An  end  item  with  a 
failure  factor  of  100  means  that,  on  average,  the  end  item  will 
fail  once  a  year. 


LINE  REPLACEABLE  UNITS  (LRUs):  The  secondary  items  spared 
forward  to  restore  an  end  item.  These  items  are  necessary  to 
accomplish  end  item  maintainability. 


MEAN  CALENDAR  TIME  BETWEEN  FAILURE  (MCTBF):  The  reciprocal  of 
the  calendar  time  failure  rate  of  an  item.  Besides  designed 
reliability,  MCTBF  also  accounts  for  the  system  operating 
tempo.  An  end  item  or  system  with  an  MCTBF  of  LOO  hours  meanc 
that,  on  average,  the  end  item  or  syste:.:  ~  M  every  100 

calendar  hours . 


MEAN  DELAY  TIME  TO  RESTORE  (MDTR) :  Average  downtime  betwet 
the  time  the  end  item  and  system  have  failed  and  the  time 
required  for  the  spare  to  be  brought  to  the  equipment.  MDTR  may 
also  represent  the  average  downtime  to  evacuate  the  equipmei.c  to 
DS,  perform  end  item  removal  and  replacement  at  DS  if 
applicable,  and  return  the  repaired  equipment  back  to  the  site. 


MEAN  LOGISTICS  DOWNTIME  (MLDT) :  Average  amount  of  downtime 
caused  by  spares  not  always  being  on-hand  to  restore  the  end 
item  and  hence  the  system.  This  downtime  can  also  be  thought  of 
as  the  average  amount  of  calendar  time  permissible  per  failure 
to  lack  spares  and  still  meet  the  system  Ao  requirement. 


MEAN  TIME  BETWEEN  FAILURE  (MTBF):  The  average  operating  hours 
per  failures.  MTBF  reflects  the  designed  reliability  based  on 
the  end  item's  or  system's  operation. 


MEAN  TIME  TO  REPAIR  (MTTR) :  The  average  hours  per  failure 
that  an  end  item  would  be  down  if  LRU  spares  are  always  on  hand 
to  restore  the  end  item  in  an  ideal  logistics  support 
environment.  MTTR  reflects  the  designed  maintainability  of  the 
end  item  or  system. 


MEAN  TIME  TO  RESTORE  (MTR) :  The  average  amount  of  time  an 
item  would  be  down  if  LRU  spares  were  always  on  hand  to  restore 
the  item  to  an  operable  condition.  Besides  designed 
maintainability,  MTR  also  accounts  for  delayed  restoral  time  in 
obtaining  on-hand  spares  from  storage,  not  always  having 
appropriately  skilled  personnel  available,  lack  of  complete  and 
correctly  written  technical  manuals,  and  not  always  having 
functioning  tools  and  test  equipment  available. 


MEAN  TIME  TO  OBTAIN  (MTTO) :  The  average  tine  it  takes  the 
most  forward  level  of  supply  support  to  receive  LRUs  when 
needed.  It  is  approximately  the  time  to  receive  LRUs  from  t  a 
next  higher  level  of  supply  plus  some  add! 1  _.arage  del.y 
time  for  that  level  of  support's  time  to  obtain  spares  from 
maintenance  or  resupply  because  its  LRU  5A  is  less  than  100%. 
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NON-OPERATING  MEAN  TIME  TO  FAILURE  (NMTTF)  ;  The  average 
non-operating  hours  per  failure  of  an  end  item  in  a  hiatus 
environment  which  is  based  on  an  equipment  not  being  in 
operation. 


OPERATING  HOURS  PER  YEAR  (OPHR):  The  average  number  of  end 
item  or  system  operating  hours  per  year.  8760  hours  per  year 
represents  full  time  equipment  operation. 


OPERATIONAL  AVAILABILITY  (Ak») :  The  probability  that  an  end 
item  or  system  will  be  in  an  operable  or  committable  condition 
at  any  random  point  in  time.  Mathematically,  it  represents  the 
percentage  of  total  calendar  time  that  the  equipment  is  up. 


ORDER  AND  SHIP  TIME  (OST):  The  average  time  from  the  need  to 
place  a  requisition  until  receipt  and  placement  of  the  order 
into  stock. 


ORDER  FILL  RATE:  The  percentage  of  equipment  failures 
requiring  the  appropriate  LRU  to  be  at  the  most  forward  level  of 
stockage  to  restore  a  failed  end  item  when  it  causes  a  system 
failure.  It  is  determined  only  for  the  most  forward  level  of 
supply  support.  The  order  fill  rate  can  only  be  equivalent  to 
SA  if  every  end  item  failure  causes  the  system  to  fail. 


STOCK  AVAILABILITY  (SA):  The  percentage  of  orders  or  demands 
for  LRUs  that  is  filled  by  the  supply  support  level  regardless 
of  whether  or  not  the  system  had  failed.  It  is  most  meaningful 
for  levels  of  supply  support  higher  than  the  most  forward  level 
of  stockage. 
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CHAPTER  12.  GLOSSARY  OF  ACRONYHS 

Operational  Availability  .  Ao 

Operational  Availability  of  a  Single  End  Item . Ao  of  1 

Average  Logistics  Downtime  .  ALDT 

Mean  Time  to  Obtain  a  Back  Order .  BOMTTO 

Depot  . . . . .  DEP 

Direct  Support  .  DS 

Failure  Factor .  FF 

General  Support  .  GS 

Hours  .  HRS 

Line  Replaceable  Units  . LRUs 

Mean  Calendar  Time  Between  Failure  .  MCTBF 

Mean  Calendar  Time  Between  Maintenance  .  MCTBM 

Mean  Downtime  . . . MDT 

Mean  Delay  Time  to  Restore  from  Direct  Support  . MDTR 

Mean  Maintenance  Downtime  . MMDT 

Mean  Shipping  and  Handling  Time  between  DS  and  GS . MSHT 

Mean  Time  Between  Failure  . MTBF 

Mean  Time  to  Repair . . . MTTR 

Mean  Time  to  Restore  . MTR 

Mean  Time  to  Obtain  Line  Replaceable  Unit  Spares  . MTTO 

Number  of  Similar  End  Items  in  a  System .  N 
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Kon-Operating  Mean  Time  to  Failure  . . . NMTTF 

Operating  Hours  per  Year  . .  OPHR 

Organizational  Level  . ORG 

Order  and  Ship  Time  . . . . . . . . . .  OS'* 

Percentage  of  Line  Replaceable  Units  Not  Repaired  .  PCiNREP 

Percentage  of  Line  Replaceable  Units  Repaired  .  PCTREP 

Number  of  Required  End  Items  Operating  for  System 

to  Be  Up  . .  R 

Repair  Cycle  Time  .  .  .  RCT 

Stock  Availability  . .  SA 


